cancel
Showing results for 
Search instead for 
Did you mean: 

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

WQ
Associate III

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

1 ACCEPTED SOLUTION

Accepted Solutions
Peter BENSCH
ST Employee

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​

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

View solution in original post

11 REPLIES 11
Peter BENSCH
ST Employee

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​

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Thanks Peter. It fixes.

-wq

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

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

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​ 

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

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

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

When your question is answered, please close this topic by clicking "Accept as Solution".
Thanks
Imen
WQ
Associate III

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

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?

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
WQ
Associate III

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