cancel
Showing results for 
Search instead for 
Did you mean: 

Why does CubeMX5.6.0 take about 250ms to process While (__ HAL_RCC_GET_FLAG (RCC_FLAG_LSERDY) == RESET) than CubeMX4.25.0?

Kyumi.1
Associate

Hello

I used CubeMX Ver.4.25.0 to run STM32F030R8T6.

One day, I decided to update the version of CubeMX, so I updated it to Ver.5.6.0.

After that, when using Ver.5.6.0, it takes about 250ms to process the code (HAL_Init () to MX_TIM16_Init ()) automatically generated by CubeMX compared to when using Ver.4.25.0. It turned out to be slow.

As I proceeded with the confirmation, I found that the following source code takes time.

--------------------- (Drivers / STM32F0xx_HAL_Drivers / Src / stm32f0xx_hal_rcc.c) ------------------ ---

   while (__ HAL_RCC_GET_FLAG (RCC_FLAG_LSERDY) == RESET)
 
   {
 
    if ((HAL_GetTick () --tickstart)> RCC_LSE_TIMEOUT_VALUE)
 
    {
 
     return HAL_TIMEOUT;
 
    }
 
   }
 

-------------------------------------------------- -------------------------------------------------- ----

It turns out that the time it takes to exit this While () is about 250ms slower.

As I proceeded with the confirmation, I found that in CubeMX Ver.5.6.0, __HAL_RCC_PWR_CLK_ENABLE () is automatically generated by HAL_Msp_Init () in main.c.

It turns out that commenting out this __HAL_RCC_PWR_CLK_ENABLE () eliminates the slowness of about 250ms.

Why is __HAL_RCC_PWR_CLK_ENABLE () now automatically generated by HAL_Msp_Init ()?

Also, if __HAL_RCC_PWR_CLK_ENABLE () is automatically generated by some bug fix, is there any way to solve the delay of about 250ms?

If it wasn't automatically generated by some bug fix, wouldn't commenting out __HAL_RCC_PWR_CLK_ENABLE () affect the operation?

I also read the release notes and reference manual, but I couldn't figure out the cause.

If anyone knows, I would appreciate it if you could let me know.

I'm Sorry for my poor English.

2 REPLIES 2

It may normally take 250ms or more to start up a 32.768kHz oscillator (seconds or even a few tens of seconds are completely normal, depending on particular crystal and PCB layout).

If you prevent Cube from enabling PWR, most probably you prevent if also from accessing the backup domain, i.e. RCC_BDCR. It may quite well be that your oscillator is still running and you prevent Cube from resetting it. Or anything else: Cube is open source so you can debug it as your own program.

JW

Hi JW,

Thank you for your response, and my understanding has deepened.

By the way, why is PWR automatically generated? Do you understand?

Is it some kind of bug fix?

Thank you very much.