SMPS - Danger the device may be destroyed

This is a ST Advertising... Nothing to comment about it?

Hi,

In this application note:

https://www.st.com/resource/en/application_note/dm00660451-how-to-build-a-lora-application-with-stm32cubewl-stmicroelectronics.pdf

I read that SMPS is also named DCDC

And searching DCDC in the End_Node source code I found:

int32_t RBI_IsDCDC(void)
 
{
 
 /* USER CODE BEGIN RBI_IsDCDC_1 */
 
 
 
 /* USER CODE END RBI_IsDCDC_1 */
 
#if defined(USE_BSP_DRIVER)
 
 /* Important note: BSP code is board dependent
 
 * STM32WL_Nucleo code can be found
 
 * either in STM32CubeWL package under Drivers/BSP/STM32WLxx_Nucleo/
 
 * or at https://github.com/STMicroelectronics/STM32CubeWL/tree/main/Drivers/BSP/STM32WLxx_Nucleo/
 
 * 1/ For User boards, the BSP/STM32WLxx_Nucleo/ directory can be copied and replaced in the project. The copy must then be updated depending:
 
 * on board RF switch configuration (pin control, number of port etc)
 
 * on TCXO configuration
 
 * on DC/DC configuration */
 
 return BSP_RADIO_IsDCDC();
 
#else
 
 /* 2/ Or implement RBI_IsDCDC here */
 
 int32_t retcode = IS_DCDC_SUPPORTED;
 
 /* USER CODE BEGIN RBI_IsDCDC_2 */
 
#warning user to provide its board code or to call his board driver functions
 
 /* USER CODE END RBI_IsDCDC_2 */
 
 return retcode;
 
#endif /* USE_BSP_DRIVER */
 
}

/**
 
 * @brief Get If DCDC is to be present on board
 
 * @note never remove called by MW,
 
 * @retval
 
 * RADIO_CONF_DCDC_NOT_SUPPORTED
 
 * RADIO_CONF_DCDC_SUPPORTED 
 
 */
 
int32_t BSP_RADIO_IsDCDC(void)
 
{
 
 return RADIO_CONF_DCDC_SUPPORTED;
 
}

static void RadioInit( RadioEvents_t *events )
 
{
 
 RadioEvents = events;
 
 
 
 SubgRf.RxContinuous = false;
 
 SubgRf.TxTimeout = 0;
 
 SubgRf.RxTimeout = 0;
 
 
 
 SUBGRF_Init( RadioOnDioIrq );
 
 /*SubgRf.publicNetwork set to false*/
 
 RadioSetPublicNetwork( false );
 
 
 
 RADIO_IRQ_PROCESS_INIT();
 
 
 
 SUBGRF_SetRegulatorMode( );
 
[...]

void SUBGRF_SetRegulatorMode( void )
 
{
 
 /* ST_WORKAROUND_BEGIN: Get RegulatorMode value from RBI */
 
 RadioRegulatorMode_t mode;
 
 
 
 if ( ( 1UL == RBI_IsDCDC() ) && ( 1UL == DCDC_ENABLE ) )
 
 {
 
 mode = USE_DCDC ;
 
 }
 
 else
 
 {
 
 mode = USE_LDO ;
 
 }
 
 /* ST_WORKAROUND_END */
 
 SUBGRF_WriteCommand( RADIO_SET_REGULATORMODE, ( uint8_t* )&mode, 1 );
 
}

So, I think in the End_Node Code, with the Nucleo-WL55 Board the SMPS is used but I don´t found any code to Enable Clock Detection like this used in PWR_SMPS example:

/**
 * @brief SMPS clock detection enable.
 * @note SMPS clock detection is recommended to be enabled before enable SMPS
 * in switching mode. 
 * In case of clock failure, it will automaticcaly switch off SMPS
 * (refer to reference manual).
 * @note SMPS clock detection is controlled through HAL SUBGHZ peripheral,
 * due to SMPS and radio related to the same HSE clock.
 * @param None
 * @retval None
 */
void SMPSClockDetectionEnable(void)
{
 uint8_t radio_register_data;
 uint8_t radio_register_data_readback;
 uint8_t radio_command;
 
 /* Enable SMPS clock detection through HAL SUBGHZ peripheral */
 HAL_SUBGHZ_ReadRegister(&hsubghz, SUBGHZ_SMPSC0R, &radio_register_data);
 radio_register_data |= SUBGHZ_SMPSC0R_CLKDE;
 HAL_SUBGHZ_WriteRegister(&hsubghz, SUBGHZ_SMPSC0R, radio_register_data);
 
 /* Check back data written */
 HAL_SUBGHZ_ReadRegister(&hsubghz, SUBGHZ_SMPSC0R, &radio_register_data_readback);
 if(radio_register_data != radio_register_data_readback)
 {
 Error_Handler();
 }
 
 /* Set back radio in Sleep mode (optional) */
 /* Note: Once clock detection is enabled the radio can be put back in Sleep mode,
 clock detection remains active.
 SMPS can still be controlled through PWR registers */
 /* Note: Using radio middleware, this action can be done more easily 
 with function "RadioSleep()" */
 radio_command = 4; /* Command "Set_Sleep": warm startup and RTC wakeup disabled is value 4 */
 HAL_SUBGHZ_ExecSetCmd( &hsubghz, RADIO_SET_SLEEP, ( uint8_t* )&radio_command, 1 );
}

QUESTION:

Should I call this function at the beginning of the End_Node application?

Best Regards,

Sergio

What I did was to modify the RBI_IsDCDC function. This function is called just before enabling the SMPS so I figured it was a good spot.

int32_t RBI_IsDCDC(void) {
 int32_t retcode = IS_DCDC_SUPPORTED;
#if IS_DCDC_SUPPORTED == 1
 
 // turn on SMPS clock detection
 SUBGRF_WriteRegister( SUBGHZ_SMPSC0R, 1 << 6);
 
 // now I can turn on the SMPS
 LL_PWR_SMPS_Enable();
#endif
 return retcode;
}

This is a pretty old thread. Maybe someone from ST will comment if this isn't a good idea.

Is this forum really dead?!

Some forum member asks a pertinent question about a warning issued by STM about one (some) of their product(s) and over TWO YEARS later nobody answered! In top of that, other members join the monologue with issues that seem related to the OP's one, this giving it more weight. Their questions remain unanswered as well. I understand other members might not be interested in the subject, or might not have any experience on the matter. That's fine. But aren't any moderators, technical people from company's side around? After all the question was related to one of their 'advertisements '...

Hey, don't mind me! I'm just a bystander. Mind these people reporting issues and asking justified questions! Big or small, they are your customers!

And how you treat them tells a lot not about them, but about who you are as a company. To me, at least, more than any shiny advertisements you pay big money for!

Thanks for getting back to me. I know I replied on the other thread, but I'll document it here too in case others aren't reading the other thread. I'm enabling the clock protection, but I think something else is going on that's APB3/SPI bus related before it even gets to the radio section. In the debugger, the SUBGHZ SPI registers all show up as 0 and never change when writing to them, and they always read back as 0. Writing anything to SPI registers in APB3 (0x58010000 region) does nothing. So it's an issue on the APB3/PCLK3 bus, before it even gets to the radio. I'm way under the 16Mhz max SPI limit, so it shouldn't be an overclocked issue that has damaged it.