Unexpected GPIO Behavior on STM32H755ZI-Q (PB14 LED)

[Duc]

Hi everyone,

This is a follow-up to my previous question about LED behavior on the STM32H755ZI-Q when using OpenAMP communication between CM4 and CM7.

https://community.st.com/t5/stm32-mcus-boards-and-hardware/nucleo-h755-led3-not-turning-on-pb14-in-ipc-example/td-p/829379 

While debugging why LED3 on PB14 was not turning on (assigned to CM7), I found a very unusual issue in the CM7 startup code generated by STM32CubeMX.

CubeMX generates the following D2 domain clock readiness loop:

timeout = 0xFFFF;
while((__HAL_RCC_GET_FLAG(RCC_FLAG_D2CKRDY) == RESET) && (timeout-- > 0));

If I rewrite the loop explicitly:

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

then PB14 suddenly starts working normally.

But here is the strange part:

If I add any variable initialization before the loop, for example:

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

then PB14 stops working again — even though the rest of the code runs correctly, OpenAMP communication works, and the other LEDs behave normally.

Important detail:

This issue affects only PB14.

• PE1 (LED2) works under all conditions

• PB0 (LED1) works under all conditions

• Any LED assigned to CM4 works under all conditions

• But PB14 (LED3) fails only when this startup loop uses a variable or the original CubeMX line

Manual toggling also fails:

HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_14);

This outputs nothing on PB14, while PE1 and PB0 toggle correctly.

---

Additional observations:

• If I assign PB14 to CM4 instead of CM7, everything works fine regardless of code version.

• The problem appears only when PB14 is used from CM7 during early startup.

• The behavior seems influenced by timing, stack use, compiler ordering, or D2 domain clock readiness.

Even though moving PB14 to CM4 solves the issue, I still want to understand the root cause:

1. Could this be related to D2 domain clock readiness timing or cross-domain clock gating?
2. Is it possible that the tiny change in code layout (variable on stack, instruction ordering, compiler optimization) changes the timing enough to cause GPIOB to be accessed before its domain is fully enabled?

I will attach the same project as in my previous post for reference.

Any insights would be greatly appreciated — this behavior is extremely odd, especially since all other GPIOs work except PB14.

Thanks in advance!