cancel
Showing results for 
Search instead for 
Did you mean: 

Update to CubeMX 6.8 adds non-working VOSRDY flag check to SystemClock_Config() on STM32F7 using LL drivers

t.decker
Senior II

Hi, I have a STM32F767 project I recently updated to new software release: CubeIDE 1.12, CubeMX6.8 (both from previous versions 1.11.x and 6.7). CubeMX code generator now adds a check for flag VOSRDY after setting regulator voltage scaling in SystemClock_Config():

LL_PWR_SetRegulVoltageScaling(LL_PWR_REGU_VOLTAGE_SCALE1);
while (LL_PWR_IsActiveFlag_VOS() == 0)
{
}

Before CubeMX 6.8 this was only the set function:

LL_PWR_SetRegulVoltageScaling(LL_PWR_REGU_VOLTAGE_SCALE1);

But the flag is never set at this stage. When I remove the check, my program runs fine again.

I also created an emtpy project based on my .ioc (just deactivated ETH, USB, FreeRTOS, TouchGFX, USB and lwIP). No additional code, just the CubeMX generated code: Same behaviour! I can provide the project when needed.

My observation of the PWR->CSR1->VOSRDY flag: It starts as 0 and gets only set to 1 later in the SystemClock_Config() function when calling

LL_RCC_PLL_Enable();

Can someone have a look at this please? ;)

When this account seems to be inactive, try @tdecker2 - ST can't change mail addresses, so I had to create a new account.
1 ACCEPTED SOLUTION

Accepted Solutions
Ghofrane GSOURI
ST Employee

Hello all, @t.decker​ @FGerh.2​  @Piranha​  @Pavel A.​ 

Thank you all for your contributions and your detailed explanations.

Issue is reproduced and it has been reported to STM32CubeMX development team .

Internal tickets number: 147617 and 147621 (This is an internal tracking number and is not accessible or usable by customers).

I will keep you posted with updates.

Thx

Ghofrane

View solution in original post

7 REPLIES 7
FGerh.2
Associate

Same thing happened to me on STM32L0 after updating to STM32Cube MCU Package for STM32L0 Devices v1.12.2.

After this update, when using LL driver for RCC, there is a change in SystemClock_Config() in main.c from

LL_PWR_SetRegulVoltageScaling(LL_PWR_REGU_VOLTAGE_SCALE1);

to

   LL_PWR_SetRegulVoltageScaling(LL_PWR_REGU_VOLTAGE_SCALE1);
  while (LL_PWR_IsActiveFlag_VOS() == 0)
  {
  }

I think this code is supposed to wait for the VOS flag in PWR_CSR which signalizes that the power regulator voltage range was successfully changed. However, according to the datasheet, the VOS flag is 1 while the voltage is changing and goes to 0 when the voltage range change is done.

Therefore, I believe the logic here is accidentally switched and the code should stay blocked while the VOS flag is 1 instead of 0.

t.decker
Senior II

Hi FGerh.2,

according to the reference manual, logic is correct for the F7 family. But yes, for the L0 the level seems switched. The flag is also called differently (VOSF vs. VOSRDY).

In my case, the flag is just not set while waiting for it. For whatever reason this happens only later, when this check is skipped.

Maybe it's also not a good idea to call the LL API function LL_PWR_IsActiveFlag_VOS when the checked register flag has a different name?

When this account seems to be inactive, try @tdecker2 - ST can't change mail addresses, so I had to create a new account.
Piranha
Chief II

RM0410 Rev 4

4.4.1 PWR power control register (PWR_CR1)

Bits 15:14 VOS[1:0]: Regulator voltage scaling output selection

These bits can be modified only when the PLL is OFF. The new value programmed is active only when the PLL is ON. When the PLL is OFF, the voltage scale 3 is automatically selected.

I'm saying it all the time - the HAL/Cube "developers" do not read the documentation...

The really sad thing is that they miss regression testing.

Ghofrane GSOURI
ST Employee

Hello all, @t.decker​ @FGerh.2​  @Piranha​  @Pavel A.​ 

Thank you all for your contributions and your detailed explanations.

Issue is reproduced and it has been reported to STM32CubeMX development team .

Internal tickets number: 147617 and 147621 (This is an internal tracking number and is not accessible or usable by customers).

I will keep you posted with updates.

Thx

Ghofrane

WGend.15
Associate II

I am also experiencing the issue with a STM32F410, seems like not just the F7 is affected

Karnigen
Associate

Same problem with STM32F411