Watchdogs Are Useful Only After the Firmware Has a Recovery Story

Resetting a stuck device is not the same as fixing it; watchdog design needs crash evidence and bounded recovery behavior.

By Reaz Romen✓ Site verified

Lab period August 2024 Published 2023-05-14 1 min read

Lab Note. Reconstructed in 2026 as a technical lab note from the 2024 telecom and embedded-systems study period. The archive date indicates the period covered; the current site publication date is shown separately.

A watchdog timer feels like instant reliability because it can reset a firmware image that stops making progress. It can also turn a reproducible bug into an endless reboot loop that destroys the evidence.

I started using the watchdog only after deciding what the device should preserve across a reset. Reset reason, boot count and a small crash marker are more useful than a silent restart. If the same firmware crashes repeatedly, the recovery policy should eventually do something different instead of repeating the same boot forever.

Task watchdogs also forced me to define what “healthy” means. Feeding the watchdog from a timer proves almost nothing. The feed should represent forward progress in the work that matters, otherwise a dead application can keep the watchdog happy.

The best outcome was not fewer resets. It was controlled resets with enough state to understand why they happened and a path to recover without user intervention.