Introduction of LL_PWR_IsActiveFlag_VOS() call in SystemClock_Config is causing freeze on start

[gospawel]

Setup - custom PCB using STM32L011G4 micro. IDE - 1.12.0 STM32CubeMX V6.8.0 STM32Cube FW_L0 V1.12.1

With latest upgrade using MX while I was changing size of the heap I was asked if I want to migrate the to latest STM32Cube firmware (6.8.0 I guess) and the code suddenly stopped working in debug. I found that it is forever locked in SystemClock_Config function in below line:

while (LL_PWR_IsActiveFlag_VOS() == 0) { }

I then checked that this line is not present if I re-generate the code using .ioc from previous commit which is using 6.7.0 version without migrating it.

I am using LL drivers for everything.

attached below is the the offending function generated by V6.8.0:

/**

• @brief System Clock Configuration

• @retval None */ void SystemClock_Config(void) { LL_FLASH_SetLatency(LL_FLASH_LATENCY_1); while(LL_FLASH_GetLatency()!= LL_FLASH_LATENCY_1) { } LL_PWR_SetRegulVoltageScaling(LL_PWR_REGU_VOLTAGE_SCALE1); while (LL_PWR_IsActiveFlag_VOS() == 0) { } LL_RCC_HSI_Enable();

  / Wait till HSI is ready / while(LL_RCC_HSI_IsReady() != 1) {

  } LL_RCC_HSI_SetCalibTrimming(16); LL_RCC_PLL_ConfigDomain_SYS(LL_RCC_PLLSOURCE_HSI, LL_RCC_PLL_MUL_4, LL_RCC_PLL_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_1); LL_RCC_SetAPB2Prescaler(LL_RCC_APB2_DIV_1); 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(32000000);

  LL_SetSystemCoreClock(32000000); LL_RCC_SetLPUARTClockSource(LL_RCC_LPUART1_CLKSOURCE_PCLK1); }

[gospawel]

Update: The process is like this: the code changes the internal regulator voltage to 1.8V in line: LL_PWR_SetRegulVoltageScaling(LL_PWR_REGU_VOLTAGE_SCALE1);

processor reacts by doing what it needs and in the next line we have waiting for a confirmation that the change has taken place: while (LL_PWR_IsActiveFlag_VOS() == 0) { }

problem is that LL_PWR_IsActiveFlag_VOS() is returning the value of the flag VOSF - and this one is set to '1' on change and then drops back to '0' when hardware gets the stable voltage. Therefore - waiting while the flag is '0' will cause what I have - permanent stop.

[HBOSTM]

Hello @gospawel ,

The issue you reported has been logged into an internal bug tracker, it will be managed by the development team. A similar issue has also been previously reported by another user. Nevertheless, this issue is related to the CubeMX generation problem and not to the firmware published in this repository. Issues related to the CubeMx tool are rather treated at the STM32CubeMX dedicated the page of the ST Community. With regards,

Best Regards,

[HBOSTM]

ST Internal Reference: 148076

[TOUNSTM]

Hi @gospawel,

Thank you for your contribution. You are absolutely right about this point. Actually, the point you raised has already been dealt and fixed internally. The fix will be made available in the frame of a future release of CubeMX.

Unfortunately we don't treat aspect related to CubeMX tool in our GitHub repositories. They are rather treated at the STM32CubeMX dedicated page of the ST Community.

Since this issue is not directly related to the STM32Cube firmware but rather to our ecosystem, please allow me then to close this thread. Thank you for your comprehension.

With regards,

[jjx591]

@gospawel Hello, I have the same problem as you and want to know how you solved it in the end?

Best Regards,

[gospawel]

@jjx591 - the only way I found to work around is to manually comment out the offending part of the function - every time I re-generate the code from .ioc file I just comment out manually these 3 lines of void SystemClock_Config(void) function:

while (LL_PWR_IsActiveFlag_VOS() == 0) { }

[jjx591]

@gospawel Thank you, I just found a temporary solution given by ST company, you can refer to it https://community.st.com/s/question/0D53W00002BefFcSAJ/stm32cubemx-680-and-stm32cubeide-1120-bug-in-the-use-of-ll