STM32H7 CubeMX critical codegeneration bug (RCC+LL)

[Wolfgang Pupp]

Bug:

CubeMX codegeneration for the RCC (clock module) may lead to hardfault during clock initialization.

I have a minimal example IOC (attached).

This faults during RCC initialization (in SystemClock_Config), after LL_RCC_SetSysClkSource(LL_RCC_SYS_CLKSOURCE_PLL1);

This happens because the peripheral domain prescalers need to be increased BEFORE switching to the faster clock (AFAICT), this would mean moving LL_RCC_SetSysClkSource(LL_RCC_SYS_CLKSOURCE_PLL1) toward the end of the function (after LL_RCC_SetAPB4Prescaler).

This is right now 100% reproducible for me, but I suspect that instruction prefetching can potentially hide/sidestep the problem: If I enable -Os optimization flags, then the problem vanishes depending on how many __NOP() instructions (0-3) are inserted directly before LL_RCC_SetSysClkSource(LL_RCC_SYS_CLKSOURCE_PLL1);.

Best way to reproduce the hardfault is single-instruction-stepping over this section with the debugger (that catches it every time for me).

Workaround:

Use HAL layer instead.

Occurred with STM32H730VBH in CubeMX v6.3.0, but I'd assume that other controllers and older CubeMX versions are also affected.

[Khouloud ZEMMELI]

Hello @Wolfgang Pupp​ ,

Thank you for your post,

I'll check it then I'll get back to you.

Khouloud

[Khouloud ZEMMELI · Accepted solution]

Hi again @Wolfgang Pupp​ ,

I have checked from my side, and I confirm the issue, you have right.

Sorry for any inconvenient that may have caused and thanks for raising this issue to our attention, it will be fixed.

Khouloud

[BCraw.1]

This bug with the LL driver is still present -  3 years later...

I moved the lines of codes setting PLL as the source AFTER the Set---PreScalar calls, and the code works. Unfortunately this fix will be blown away the next time I generate code from CubeMX.

This is with the latest versions of everything as of 11-21-24 and using a H757 target. I guess I'll try the bloated HAL version. :(