STM32U375 - System Lockup instead of Reset when IWDG_STDBY_FREEZE is enabled

[ZacchetG]

Hi everyone, I am encountering a critical issue with the IWDG on an STM32U375 using STM32CubeMX v6.17.0 and a Segger J-Link Base.

The scenario: I am testing the Watchdog behavior across Standby cycles. I have configured the Option Bytes via software to freeze the watchdog during low power modes:

• IWDG_SW: 1 (Software mode)

• IWDG_STOP_FREEZE: 0 (Counter stops in Stop mode)

• IWDG_STDBY_FREEZE: 0 (Counter stops in Standby mode)

The Issue: When the system is in IWDG_STDBY_FREEZE mode, the following happens:

1. The MCU wakes up from Standby correctly.

2. I enter a test while(1) loop without refreshing the IWDG.

3. At the exact moment the IWDG timeout should occur (10s), the MCU enters an unrecoverable state.

   • No System Reset occurs.

   • No HardFault_Handler is triggered.

   • The CPU seems to be completely locked (Bus Lockup?).

4. I tried to enable the IWDG Early Wakeup Interrupt (EWI) via NVIC, but HAL_IWDG_EarlyWakeupCallback() is never called before the crash.

Contrast with RUN mode: If I change the configuration to IWDG_STDBY_RUN (Watchdog active during Standby), the system works perfectly: the IWDG expires and triggers a clean System Reset as expected.

Environment & Debugging:

• IDE/Tool: STM32CubeMX 6.17.0 / Segger J-Link Base.

• Clock: LSI is stable and verified.

• Observations: When the "Freeze" mode is active, the transition from "Frozen" (in Standby) to "Active" (after Wakeup) seems to lead to a hardware deadlock upon counter expiration. It feels like the IWDG reset signal is being masked or is causing a bus hang instead of a global reset.

Questions:

1. Is there a known errata or specific synchronization requirement for the IWDG on the U3 series when resuming from a "Frozen" state in Standby?

2. Why would the IWDG NVIC interrupt fail to trigger even when configured, only in this specific Freeze scenario?

3. Could the J-Link's handling of the DBGMCU freeze bits interfere with the Option Bytes configuration in a way that causes a bus lockup?

Any insights or suggestions on how to further debug this "unrecoverable state" would be greatly appreciated.

Thank you in advance for your support and insights.

Best regards,

Gianni

[Gyessine]

Hello @ZacchetG 
>The MCU wakes up from standby correctly.
Can you explain how you wake up the system from standby? For example, do you use the RTC, a wakeup pin, or another method?
>I enter a test while (1) loop without refreshing the independent watchdog (IWDG).
Can you share a piece of your code? Waking up from standby creates a system reset, so how do you enter a while loop without the system resetting and starting over?
>The MCU enters an unrecoverable state.
Can you share more details about this unrecoverable state? Are you using debug mode, or does this occur even when you just flash the project?
BR
Gyessine

[alex95]

Root Cause discovered: On my custom PCB, the PH3-BOOT0 pin is shared with an ePaper display reset line, which has an internal pull-up. With the default factory Option Bytes (nSWBOOT0=1), the MCU was sampling the PH3 pin high during the IWDG reset, causing the system to jump into the System Bootloader (0x0BF8 F000) instead of restarting the application.

Resolution: I modified the Option Bytes to:

• nSWBOOT0 = 0 (Ignore physical BOOT0 pin)
• nBOOT0 = 1 (Force Boot from Flash)

With this configuration, the IWDG reset works perfectly regardless of the state of the PH3 pin.

You can close the case. Best regards.

Gianni Z.

[Gyessine]

@alex95 @ZacchetG 

Thank you for returning and sharing the root cause with the community.
BR
Gyessine