stm32cube: stm32g4xx: wrong clock setup

[FRASTM]

When configuring the PLL > 80MHz, an intermediate step is needed
with AHB prescaler set to 2 before setting the actual value.
In case the actual value is AHB prescaler 1, it must be set, though.

This will fix zephyrproject-rtos/zephyr#21715

Signed-off-by: Francois Ramu [email protected]

[erwango]

Please update patch list section in package readme file.
Also please provide ST internal tracking number

[FRASTM]

stm32cube/stm32g4xx/README file updated

[martinjaeger]

Just found that this PR fixed the LED blinky issue, but causes a wrong setting of SysCoreClock variable (75 MHz instead of actual 150 MHz frequency for the Nucleo STM32G431). This leads to wrong UART baud rate settings (that's how we discovered it) and possibly other issues...

In case of PLL frequency >80 MHz, the following call

hal_stm32/stm32cube/stm32g4xx/drivers/src/stm32g4xx_ll_utils.c

Line 325 in 94d735c

status = UTILS_EnablePLLAndSwitchSystem(pllfreq, UTILS_ClkInitStruct);

sets also SysCoreClock to hclk, which is the preliminary lower AHB frequency, pllfreq / 2:

hal_stm32/stm32cube/stm32g4xx/drivers/src/stm32g4xx_ll_utils.c

Line 657 in 94d735c

LL_SetSystemCoreClock(hclk_frequency);

However, the call

hal_stm32/stm32cube/stm32g4xx/drivers/src/stm32g4xx_ll_utils.c

Line 331 in 94d735c

LL_RCC_SetAHBPrescaler(UTILS_ClkInitStruct->AHBCLKDivider);

afterwards only sets the AHB prescaler to final value, but does not update the SysCoreClock anymore.

@FRASTM can you please have a look? Thanks!

Can we try to get this fixed before Zephyr release 2.2 merge window closes? Otherwise the STM32G4 is hardly useable.

(posting here, as I can't open an issue in this repo).