2025-07-15 11:54 AM
I generate project for g431 in STM32CubeIDE Version: 1.19.0 and HAL generated code is setting PLLCFGR correctly but switching to LL values are not entered.
Code generated for LL below:
/**
* @brief System Clock Configuration
* @retval None
*/
void SystemClock_Config(void)
{
LL_FLASH_SetLatency(LL_FLASH_LATENCY_4);
while(LL_FLASH_GetLatency() != LL_FLASH_LATENCY_4)
{
}
LL_PWR_EnableRange1BoostMode();
LL_RCC_HSE_Enable();
/* Wait till HSE is ready */
while(LL_RCC_HSE_IsReady() != 1)
{
}
LL_RCC_PLL_ConfigDomain_SYS(LL_RCC_PLLSOURCE_HSE, LL_RCC_PLLM_DIV_2, 85, LL_RCC_PLLR_DIV_2);
LL_RCC_PLL_EnableDomain_SYS();
LL_RCC_PLL_Enable();
/* Wait till PLL is ready */
while(LL_RCC_PLL_IsReady() != 1)
{
}
LL_RCC_SetSysClkSource(LL_RCC_SYS_CLKSOURCE_PLL);
LL_RCC_SetAHBPrescaler(LL_RCC_SYSCLK_DIV_2);
/* Wait till System clock is ready */
while(LL_RCC_GetSysClkSource() != LL_RCC_SYS_CLKSOURCE_STATUS_PLL)
{
}
/* Insure 1us transition state at intermediate medium speed clock*/
for (__IO uint32_t i = (170 >> 1); i !=0; i--);
/* Set AHB prescaler*/
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_SetSystemCoreClock(170000000);
/* Update the time base */
if (HAL_InitTick (TICK_INT_PRIORITY) != HAL_OK)
{
Error_Handler();
}
}
Code is not following manual which says:
To modify the PLL configuration, proceed as follows:
1. Disable the PLL by setting PLLON to 0 in Clock control register (RCC_CR).
2. Wait until PLLRDY is cleared. The PLL is now fully stopped.
3. Change the desired parameter.
4. Enable the PLL again by setting PLLON to 1.
5. Enable the desired PLL outputs by configuring PLLPEN, PLLQEN, PLLREN in PLL
configuration register (RCC_PLLCFGR).
PLL is not stopped in LL driver. Adding LL_RCC_PLL_Disable() is fixing this.
2025-07-15 12:00 PM
What's the point of HAL vs LL drivers if they do the exact same thing?
In order for LL to be stripped down, you have to miss out on functionality. Assuming the clock is in the as-reset state during SystemClock_Config seems a reasonable assumption.
2025-07-15 12:15 PM - edited 2025-07-15 12:24 PM
So what is the point of generating code that is not working?
But suppose you are right than can you point me to information where all LL quirks/limitations are explained?
And just look at the code. They are starting PLL without stopping it before. Makes not sense.
And it is not LL function error. It is not completed code generated by CubeIDE
2025-07-15 1:11 PM
I worked with LL years ago and didn’t encounter this issue back then, so I started wondering what’s going on now.
Previously, I mainly used Nucleo boards, and everything worked fine. But now I’m using a custom board with a J-Link debugger, and the debug interface only uses SWDIO and SWDCLK. It seems that a software reset doesn’t fully restore all registers. So when I start a new debug session without triggering a hardware reset via NRST, the PLL is still running from before. As a result, SystemClock_Config doesn’t properly reconfigure the PLL.
2025-07-15 1:22 PM
The PLL is disabled when the chip boots. If your debugger configures it to some non-reset state, that is the reason it's failing.
2025-07-15 2:24 PM
I also checked the Ozone debugger with the same J-Link, and there is a much higher chance that RCC_CR.PLON gets reset after starting debugging and performing a reset. However, sometimes it still remains ON...
No time to dig it more. But maybe it may be useful for someone else.
2025-07-16 4:16 AM
Hello @PHryn
I am currently investigating this issue and will get back to you as soon as possible.
I would appreciate it if you could kindly share your IOC file.
Thank you,
Ghofrane
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.
2025-07-16 6:42 AM
Hello @Ghofrane GSOURI,
For debugging, I use a J-Link with only two lines: SWDIO and SWDCLK—no NRST. This issue cannot be reproduced with an ST-Link.
On the other hand, when debugging the same program using Segger Ozone, the debugger fails to clear the PLLON bit on the first connection. However, after each subsequent download, PLLON is properly reset.
A simple modification in SystemClock_Config can mitigate this issue. I believe most boards only expose SWDIO and SWDCLK, and when using a J-Link, this situation can be quite common if the PLL is enabled without being explicitly disabled beforehand.