STM32U585 Cannot switch between SMPS and LDO power supplies

[JKahn.1]

I am using the B-U585I-IOT02A discovery kit with the STM32U585AI chip.

Using code generated by STM Cube.

Attempting to configure use of the SMPS power supply results in a timeout in the  HAL_PWREx_ConfigSupply() function.

In the sequence below, smps_mode remains the same after each function call. The HAL_PWREx_ConfigSupply(PWR_SMPS_SUPPLY); call returns a timeout.

Why? I should be able to switch back and forth between LDO and SMPS, and the dev kit seems to have the proper hardware to support SMPS.

STM32CubeIDE Version: 1.12.0 Build: 14980_20230301_1550 (UTC)

  uint32_t smps_mode = HAL_PWREx_GetSupplyConfig();
  HAL_PWREx_ConfigSupply(PWR_LDO_SUPPLY);
  smps_mode = HAL_PWREx_GetSupplyConfig();
  HAL_PWREx_ConfigSupply(PWR_SMPS_SUPPLY);
  smps_mode = HAL_PWREx_GetSupplyConfig();

[Frantz LEFRERE · Accepted solution]

Hello @JKahn.1​ ,

please insure there is a call to

 __HAL_RCC_PWR_CLK_ENABLE();

Before trying to change this configuration.

Usually this is done in "void HAL_MspInit(void)" function

[JKahn.1]

That function is called in HAL_MspInit() as generated by Cube...

Might be a different issue?

void HAL_MspInit(void)

{

 /* USER CODE BEGIN MspInit 0 */

 /* USER CODE END MspInit 0 */

 __HAL_RCC_PWR_CLK_ENABLE();

 /* System interrupt init*/

 /* USER CODE BEGIN MspInit 1 */

 /* USER CODE END MspInit 1 */

}

[JKahn.1]

Note this also helped solve another issue I was having:

https://community.st.com/s/question/0D53W00002DCKGUSA5/stm32u585-systemclockconfig-failure-to-configure-voltage-scaling?t=1680725780983

I looked at a project generated for the STM32L5 and noticed there another function call in HAL_MspInit(), to __HAL_RCC_SYSCFG_CLK_ENABLE();.

Added that to my STM32U5 project and now it seems to be working as expected

[JKahn.1]

I tried it again, you are correct. The call to __HAL_RCC_PWR_CLK_ENABLE() on its own is enough to get the smps selection working using HAL_PWREx_ConfigSupply()

[DDrin.1]

For me, this was also indirectly my issue.

At first it seemed it wasn't my issue, since I had a call to __HAL_RCC_PWR_CLK_ENABLE() in my HAL_MspInit() function:

/* USER CODE END 0 */
/**
* Initializes the Global MSP.
*/
void HAL_MspInit(void)
{
/* USER CODE BEGIN MspInit 0 */

/* USER CODE END MspInit 0 */

__HAL_RCC_PWR_CLK_ENABLE();   // <---- Already here!
HAL_PWREx_EnableVddA();

/* System interrupt init*/

/** Enable the VREF clock
*/
__HAL_RCC_VREF_CLK_ENABLE();

...

However, forcing a call to __HAL_RCC_PWR_CLK_ENABLE() in my main() function before calling HAL_PWREx_ControlVoltageScaling(PWR_REGULATOR_VOLTAGE_SCALE1) fixed the issue:

void SystemClock_Config(void)
{
    RCC_OscInitTypeDef RCC_OscInitStruct = {0};
    RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};

    __HAL_RCC_PWR_CLK_ENABLE();    // <---- Force add a call here in my main.c
    /** Configure the main internal regulator output voltage
    */
    if (HAL_PWREx_ControlVoltageScaling(PWR_REGULATOR_VOLTAGE_SCALE1) != HAL_OK)
    {
        Error_Handler();
    }

So clearly my HAL_MspInit() function wasn't being called, otherwise this fix wouldn't help.

I can see from grepping my Cube generated code and the HAL library code that HAL_MspInit() is not explicitly called by my Cube generated code, but rather as a weakly declared function called by the HAL -- that is, the HAL will call it if it's defined, but won't care if it's not defined and will continue on as if nothing is wrong.

So... finally putting the pieces together, I realized I must not actually be compiling the stm32u5xx_hal_msp.c code file -- the file where HAL_MspInit() is defined, by my Cube generated code. I know it's in the list of files to be compiled, however... Indeed, I see that I had it compiled as part of the library target I created, rather than the main executable target. Moving it to the main executable target fixed the issue!

Note that I ported the Cube generated code to Cmake using https://github.com/ObKo/stm32-cmake to help package the HAL and CMSIS into proper Cmake targets. Putting the stm32u5xx_hal_msp.c in the wrong Cmake target was my mistake when doing the port.