The simplest and most basic LL driver App doesn't work

[WQ_it]

We tried the simplest and the most basic LL driver based App, LED blinking, on Nucleo boards:

int main(void)
{
 LL_APB2_GRP1_EnableClock(LL_APB2_GRP1_PERIPH_SYSCFG);
 LL_APB1_GRP1_EnableClock(LL_APB1_GRP1_PERIPH_PWR);
 NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_4);
 SystemClock_Config();
 MX_GPIO_Init();
 MX_USART2_UART_Init();
 while (1)
 {
 LL_GPIO_TogglePin(LD3_GPIO_Port, LD3_Pin);
 LL_mDelay(1000);
 }
}

Comments and empty lines are removed. We just added two lines of code in the while loop. Everything else is from MX. (LED pin changes with different Nucleo boards).

Well, it doesn't work. It failed on Nucleo-L432KC and Nucleo-L452RE. Both are L4 MCU so they use the same FW and library. It can't pass through the system clock configuration. The MCO output of the internal PLL has no life at all.

However, it works on Nucleo-WB55RG. The LED is blinking!

Is there anything I missed in LL based programming? or is there anything to fix for L4 firmware and library?

Thanks. -wq

[Peter BENSCH]

Apparently you have stumbled across a small bug inserted by STM32CubeMX:

In main.c, SystemClock_Config(), the voltage scaling is set and then the corresponding flag is checked incorrectly:

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

should be changed to:

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

Explanation:

LL_PWR_SetRegulVoltageScaling() sets bits VOS in PWR_CR1 (RM0394, 5.4.1)

LL_PWR_IsActiveFlag_VOS() checks the corresponding bit VOSF in PWR_SR2 (RM0394, 5.4.6):

Typically, the return value 0 stands for OK or HAL_OK, so LL_PWR_IsActiveFlag_VOS() returns the correct value, but STM32CubeMX inserts the wrong comparison so that the while loop is never exited on OK.

Temporary fix until this is corrected: after each generation of the code by STM32CubeMX, the mentioned comparison in SystemClock_Config() has to be corrected manually from == 0 to !=0 (line 2 in the snippet mentioned above).

Hope that helps?

Regards

/Peter

@Imen DAHMEN​

[WQ_it]

Thanks Peter. It fixes.

-wq

[Peter BENSCH]

Great!

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.

Regards

/Peter

[waclawek.jan]

Hi Peter,

this spectacular piece of clairvoyancy is no coincidence, is it....

Can you please start an appropriately titled thread describing the circumstances when this bug occurs - i.e. which STM32 models are affected, which CubeMX version - so that we can refer to it in the future when this comes up?

Because this will come up.

Yes, nobody is proud of making a bug - but, as the saying goes, there are only two kinds of programmers - those, who make bugs, and those who don't admit it.

Thanks,

Jan

@Peter BENSCH​ 

[Peter BENSCH]

Thanks, Jan, for pointing this out.

I actually didn't find that either until I recreated the problem well described by @Community member​ on a NUCLEO and added a sticky topic under STM32CubeMX.

Regards

/Peter