Possible Timeout Logic Bug in STM32CubeMX Generated Code (RCC_FLAG_D2CKRDY)

[Duc]

Hello ST team and community,

I am working with STM32H755 and noticed a potential bug in the code generated by STM32CubeMX when handling the RCC_FLAG_D2CKRDY check during system initialization. CubeMX produces two variants of the loop:

while((__HAL_RCC_GET_FLAG(RCC_FLAG_D2CKRDY) != RESET) && (timeout-- > 0));
if (timeout < 0)
{
    Error_Handler();
}

and

while((__HAL_RCC_GET_FLAG(RCC_FLAG_D2CKRDY) == RESET) && (timeout-- > 0));
if (timeout < 0)
{
    Error_Handler();
}

Issue observed

• The loop condition uses (timeout-- > 0).

• This means the loop exits when timeout reaches 0, but never decrements below zero.

• As a result, the check if (timeout < 0) will never be true, so Error_Handler() is never called — even if the D2 domain clock never becomes ready.

Since STM32H755 relies on proper synchronization between the Cortex‑M7 and Cortex‑M4 domains, missing this error condition can mask serious startup failures. Developers may assume the system initialized correctly when in fact the D2 domain clock never stabilized.

Could ST confirm whether this is a known issue in STM32CubeMX for STM32H7 series (specifically STM32H755)?

Thanks for your support!

[Ghofrane GSOURI]

Hello @Duc 

I'm currently checking this behavior. I will get back to you asap.

THX

Ghofrane

[TDK · Accepted solution]

This works. "timeout--" will post-decrement and the value will be -1 after the loop exits. Try it. Compared to "--timeout" which will pre-decrement and not work here.