STM32L4+ HAL RCC PLL Initialization Regression

[Rob.Riggs]

Since upgrading from STM32Cube MCU Package for STM32L4 from 1.17.1 to 1.17.2 (or 1.18.0), when disabling the PLL, HAL_RCC_OscConfig() will fail with HAL_TIMEOUT.

I reconfigure the oscillators and PLL to run at 4 different speeds, depending on mode: 2MHz MSI (idle), 16MHz HSI (startup), and either 48MHz or 72MHz HSE (run) depending on state. The PLL is only enabled in run mode.

The issue appears to be that HAL_RCC_OscConfig() will stop the clock feeding the PLL before the PLL is disabled. When that happens, PLLRDY does not change after setting PLLON to 0. This results in what is shown below, where PLLON is 0, PLLRDY remains 1, and HAL_RCC_OscConfig() fails with HAL_TIMEOUT.

The work-around I have in place is to call __HAL_RCC_PLL_DISABLE() before calling HAL_RCC_OscConfig() where the PLL will being disabled. I am not sure what exactly changed in the HAL to trigger this problem. There are changes in 1.17.2 in the section of code that disables the PLL.

The fix would seem to be to change the function to disable PLLs, if so requested, before any oscillators are changed and enable PLLs only after the oscillators are configured.

Minimal reproducer is available here: https://github.com/mobilinkd/HAL_RCC_OscConfig_TIMEOUT

This requires a STM32L432KC Nucleo32 board with SB17 shorted to provide HSE.

The requirements to trigger the bug are:

1. Have an oscillator configured and feeding the PLL, and the PLL enabled.
2. Create a configuration which will disable both the PLL and the oscillator.
3. Call `HAL_RCC_OscConfig()`

[Saket_Om]

Hello @Rob.Riggs 

 

I attempted to reproduce your issue using the code you provided on GitHub. The HAL_RCC_OscConfig() API returns HAL_TIMEOUT, but it is not the PLL Ready check that fails. Instead, the failure occurs during the HSE Ready check.

[Rob.Riggs]

@Saket_Om Is SB17 shorted on your board? HSE timeout will occur if this step in the instructions is not followed.

[Saket_Om]

Hello @Rob.Riggs 

 

Your reported issue is being taken into consideration and has been assigned the internal ticket number 186497 for a detailed investigation.

It is an internal tracking number and is not accessible or usable by customers.

[RAJMAI]

Hello @Rob.Riggs,

I have tested your project with STM32Cube versions V1.17.2, V1.17.1, and even V1.17.0. The behavior remains the same, indicating that this is not a regression.

Otherwise  i managed to reproduce your problem. Indeed, in the second call to  HAL_RCC_OscConfig within the SysClock2 function, the function returns HAL_TIMEOUT because the elapsed time to check that the RCC_CR_PLLRDY flag is 0 is not sufficient.

 

Your decision to add __HAL_RCC_PLL_DISABLE before calling HAL_RCC_OscConfig is merely a time-saver; the function is already called within PLL Configuration and works fine.

 

 

 

I recommend increasing the PLL_TIMEOUT_VALUE to 10 ms, for example. I tried this adjustment, and the example works fine for me.

 

Can you try it? I am waiting for your feedback.

 

Regards,

Rania