Skip to main content
YLi.13
Associate II
April 29, 2023
Solved

When I used NUCLEO-F446RE to debug the STM32 program, I found that the program execution was stuck for a long time in the "LL_PWR_IsActiveFlagVOS()" function. How can I solve this problem?

  • April 29, 2023
  • 3 replies
  • 2192 views

The clock initialization code is generated by STM32CubeIDE

void SystemClock_Config(void)
{
 LL_FLASH_SetLatency(LL_FLASH_LATENCY_5);
 while(LL_FLASH_GetLatency()!= LL_FLASH_LATENCY_5)
 {
 }
 LL_PWR_SetRegulVoltageScaling(LL_PWR_REGU_VOLTAGE_SCALE1);
 while (LL_PWR_IsActiveFlag_VOS() == 0)
 {
 }
 LL_PWR_EnableOverDriveMode();
 LL_RCC_HSE_EnableBypass();
 LL_RCC_HSE_Enable();
 
 /* Wait till HSE is ready */
 while(LL_RCC_HSE_IsReady() != 1)
 {
 
 }
 LL_RCC_PLL_ConfigDomain_SYS(LL_RCC_PLLSOURCE_HSE, LL_RCC_PLLM_DIV_4, 180, LL_RCC_PLLP_DIV_2);
 LL_RCC_PLL_Enable();
 
 /* Wait till PLL is ready */
 while(LL_RCC_PLL_IsReady() != 1)
 {
 
 }
 LL_RCC_SetAHBPrescaler(LL_RCC_SYSCLK_DIV_1);
 LL_RCC_SetAPB1Prescaler(LL_RCC_APB1_DIV_4);
 LL_RCC_SetAPB2Prescaler(LL_RCC_APB2_DIV_2);
 LL_RCC_SetSysClkSource(LL_RCC_SYS_CLKSOURCE_PLL);
 
 /* Wait till System clock is ready */
 while(LL_RCC_GetSysClkSource() != LL_RCC_SYS_CLKSOURCE_STATUS_PLL)
 {
 
 }
 LL_Init1msTick(180000000);
 LL_SetSystemCoreClock(180000000);
 LL_RCC_SetTIMPrescaler(LL_RCC_TIM_PRESCALER_TWICE);
}

This topic has been closed for replies.
Best answer by Peter BENSCH

No one has claimed that you can only generate this code with HAL. CubeMX currently relies on two library types: the older and, for some users, simpler HAL and the younger and more memory-saving LL, for whose use, however, one definitely needs to know the hardware very precisely, more precisely than with the HAL. 

If you now set the block RCC to LL with CubeMX or CubeIDE, you will get your initialisation code generated, which currently still has the small bug mentioned above and sets the comparison incorrectly. Actually, only the == has to be replaced by !=, but CubeMX overwrites this the next time the programme is generated if something has changed in the IOC.

3 replies

Peter BENSCH
Technical Moderator
April 29, 2023

This is a known bug of STM32CubeMX, which will be fixed soon and for which a temporary solution is proposed here.

Sorry for the inconvenience and hope that helps?

If the problem is solved, please mark this thread as answered by selecting Select as best, as also explained here. This will help other users find that answer faster.

Good luck!

/Peter

YLi.13
YLi.13Author
Associate II
April 30, 2023

So I can only generate this code using the HAL library?

Peter BENSCH
Peter BENSCHBest answer
Technical Moderator
April 30, 2023

No one has claimed that you can only generate this code with HAL. CubeMX currently relies on two library types: the older and, for some users, simpler HAL and the younger and more memory-saving LL, for whose use, however, one definitely needs to know the hardware very precisely, more precisely than with the HAL. 

If you now set the block RCC to LL with CubeMX or CubeIDE, you will get your initialisation code generated, which currently still has the small bug mentioned above and sets the comparison incorrectly. Actually, only the == has to be replaced by !=, but CubeMX overwrites this the next time the programme is generated if something has changed in the IOC.

YLi.13
YLi.13Author
Associate II
May 1, 2023

ST's Cube ecosystem is a very convenient and grand system, and I hope it will become even more perfect. Thank you for your reply.

YLi.13
YLi.13Author
Associate II
April 30, 2023

By the way, can I confirm that the HSE of the Nucleo board needs to be set to "by pass"?


_legacyfs_online_stmicro_images_0693W00000bj6F5QAI.png

Peter BENSCH
Technical Moderator
April 30, 2023

Correct, with this type of NUCLEO (MB1136) the crystal X3 is not equipped and the clock for HSE is used from the signal MCO of the already existing ST-LINK/V2-1. For this reason, the HSE of the target (here STM32F446RE) must be set to bypass so that the clock fed into RCC_OSC_IN can be used as HSE.