Watchdog timers before the mystery reboot

Why watchdogs exist

Embedded systems freeze. A cosmic ray flips a bit, your I²C bus hangs waiting for a clock stretch that never ends, or a pointer walks off into the weeds. The firmware doesn't crash—it just stops making progress. No exception, no blinking LED, no serial output. Just silence.

A watchdog timer is a small hardware counter that resets your microcontroller if your code doesn't check in regularly. It's the difference between a robot that quietly stops responding and one that reboots itself and logs the failure.

Configuration that actually helps

Most datasheets bury the watchdog settings in a forest of register bits. You want a timeout long enough that normal operation never triggers it, but short enough that users notice the reboot instead of the hang.

For a control loop running at 100 Hz, a one-second watchdog is reasonable. For a sensor logger that wakes every ten seconds, five seconds works. The key is knowing your longest legitimate code path—including I²C retries, flash writes, and any blocking waits you haven't eliminated yet.

On ARM Cortex-M parts, the independent watchdog (IWDG) runs off its own RC oscillator. It keeps ticking even if your main clock dies. Configure it once during init, then pet it from your main loop or a high-priority task. Don't pet it from an interrupt unless you're certain that interrupt will always fire.

Logging the reset cause

A watchdog reset is useful data. Most microcontrollers preserve a reset-cause register through the reboot. Read it early in your startup code, before anything else clobbers it, and write the value to non-volatile storage or send it over your debug interface.

Distinguish between power-on resets, brownouts, and watchdog timeouts. If you're seeing regular watchdog resets in the field, you have a bug—probably a state machine that doesn't return, a peripheral that locks, or interrupt-driven sensor reads that stopped firing. The log tells you where to start.

Petting without lying

The temptation is to sprinkle watchdog resets throughout your code like seasoning. Don't. Pet the watchdog in exactly one place—ideally at the top of your main loop, after you've confirmed that all critical tasks completed successfully.

If you pet it from five different functions, you've just created five ways for the firmware to look alive while actually being stuck. A tight loop that pets the watchdog every millisecond defeats the entire point.

Some systems use a software watchdog on top of the hardware one: a high-priority task that only pets the hardware timer if lower-priority tasks have checked in recently. This catches priority inversions and runaway loops that still service interrupts.

Testing the safety net

Before you ship, deliberately hang the firmware and confirm the watchdog catches it. Comment out the pet call, or add an infinite loop in a rare code path. The system should reboot cleanly within your configured timeout, and your reset-cause register should show a watchdog event.

If it doesn't, your watchdog isn't enabled, your timeout is misconfigured, or you're petting it from the wrong context. Fix it now, because the first time it matters will be in a deployment you can't easily reach.

When not to use one

If your system has external interlocks—a motor driver with its own enable line, a relay that cuts power, a separate safety processor—coordinate the watchdog with those. A microcontroller that reboots every two seconds because of a persistent hardware fault is worse than one that fails safe and stays stopped.

For battery-powered nodes that sleep for hours, the watchdog may burn more power than it's worth. In those cases, an external supervisor IC with a longer timeout and lower quiescent current makes more sense.

Field behavior

A well-tuned watchdog is invisible until it isn't. Your logs will show occasional resets during development—usually I²C bugs or state machines with missing exit conditions. In production, watchdog resets should be rare enough to investigate individually.

If you're seeing them weekly, you have a latent bug. If you're seeing them never, either your system is bulletproof or your watchdog isn't armed. Assume the latter until proven otherwise.