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 @TDK 

Thank you for bringing this to our attention.

Issue has been escalated to dev team for further investigation and resolution.

Internal ticket number 223119  

I will keep you posted with updates.

THX

Ghofrane

[TDK]

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.