How do you handle the watchdog during debugging?

Debugging and watchdogs are inherently in conflict. When you hit a breakpoint, the CPU halts — but hardware timers keep counting (they are not on the CPU pipeline). If you pause at a breakpoint for longer than the watchdog timeout, the system resets, the debug session disconnects, and you lose your inspection context. This is especially frustrating when debugging the exact code path that feeds the watchdog, because you cannot step through it without triggering the timeout.

STM32 solution: The DBGMCU (Debug MCU Configuration) peripheral has freeze bits that halt specific timers when the CPU is halted by the debugger. Setting DBGMCU_APB1_FZ.DBG_IWDG_STOP freezes the IWDG counter during debug halt, and DBGMCU_APB1_FZ.DBG_WWDG_STOP freezes the WWDG. The HAL provides convenience macros: __HAL_DBGMCU_FREEZE_IWDG() and __HAL_DBGMCU_FREEZE_WWDG(). Enable these early in your initialization code (before starting the watchdogs) so they take effect for the entire debug session.

Critical rule: These freeze bits must not be present in production firmware. If a debugger probe is accidentally left connected in the field (not uncommon during manufacturing test), or if the DBGMCU registers are not cleared after a debug session, the watchdog might not function correctly when the CPU enters a low-power halt state. Use conditional compilation to restrict watchdog freeze to debug builds only:

#ifdef DEBUG
    __HAL_DBGMCU_FREEZE_IWDG();
    __HAL_DBGMCU_FREEZE_WWDG();
#endif

Some teams also increase the watchdog timeout in debug builds (e.g., 10 seconds instead of 500 ms) as additional margin for stepping through code. This is less safe than the freeze approach but useful when the DBGMCU freeze feature is not available on a particular MCU.