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

[WQ]

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 · Accepted solution]

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]

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

[Imen.D]

Hi Peter,

Sorry for my late answer as I was out of Office.

I already escalated this issue internally and will be fixed by CubeMx team.

Internal ticket is submitted: Ticket ID 147842 (PS: This is an internal tracking number and is not accessible or usable by customers).

Imen

[WQ]

Imen:

It was not that simple as Peter found. The bug is deep and much bigger.

Peter's trick did fix for NUCLEO_L432KC, but not for NUCLEO_L452RE. After Peter posted, I tried and it worked for L432KC. I then got analog problem on L432KC (I have had a few posts for last few days). I switched to L452RE today. The codes are easily ported from L432KC to L452RE. It was simply dead. I had to go to ground 0 of LED blinking (and applied Peter's trick of course). Switching back to HAL (it had only HSE and LD4 and HAL), it didn't work (the LED not blinking, thank you very much for putting a LED on NUCLEO board). It worked only when HSI is used. In other words, MX got broken fundamentally when HSE is turned on.

-wq

[Peter BENSCH]

Well, did you take into account that there is no crystal populated on the NUCLEO-L452RE and the HSE clock comes by bypass from the MCO (8MHz) of the ST-LINK/V2-1?

[WQ]

No, I didn't know. It is indeed that X3 is not populated. Sorry. -wq