A Watchdog Is Not a Nice-to-Have

What this is. Opinion + Experience + Fact (35% opinion · 40% experience · 25% fact). Written in collaboration with AI — I discuss, I do not outsource.

Why a hung embedded device is more dangerous than a crashed one, and how a hardware watchdog turns a silent freeze into an automatic recovery. The short version: a watchdog is a hardware timer your firmware must keep resetting; if the firmware hangs and stops resetting it, the timer expires and reboots the chip — but only if you "kick" it honestly, when real work is happening.

Here's a failure mode that unsettles every embedded engineer the first time they meet it. A device doesn't crash — it hangs. The main loop gets stuck: a deadlock, an infinite wait on a peripheral that never answers, a corrupted state the code can't get out of. Power is still on. The network link is still up. From the outside, and often from your own dashboard, the device looks perfectly healthy. It's just not doing anything. And a crash, by comparison, is the lucky case — it reboots and comes back. A hang can sit there for hours or days until a customer calls.

The humble hardware watchdog exists for exactly this, and it's one of the most-skipped safeguards in the field. Here's how to think about it.

---

1. A hang is worse than a crash

A crash is loud and self-correcting: the processor faults, resets, and resumes. A hang is quiet. The firmware is technically still "running" — the CPU is executing instructions — it's just executing the wrong ones forever, or waiting on something that will never happen. Nothing faults, so nothing reboots. The dangerous part is the mismatch between how the device looks and what it's doing: to monitoring it reads as "up," to the user it's dead. That gap is where a whole class of field failures lives, and it's invisible until someone external notices.

▸ First principle. The dangerous failure isn't the one that falls over, it's the one that freezes while looking alive.

2. The watchdog is the chip's dead-man's switch

A watchdog timer is a piece of hardware that counts down on its own, independent of your application code. Your firmware's job is to periodically reset that countdown before it reaches zero — the industry calls it "kicking," "petting," or "feeding" the watchdog. As long as the firmware is looping and making progress, it keeps kicking, and the timer never expires. The moment the firmware hangs and stops kicking, the timer runs out and forces a hardware reset. The device reboots and recovers itself, with no one on site and no support ticket required. Because the watchdog lives outside the CPU's normal execution, it can rescue the system from a state the CPU's own code got stuck in.

▸ First principle. A device should be able to rescue itself from a state its own code got stuck in.

3. Kick it honestly, not blindly

Here's the trap that makes a watchdog worse than useless: kicking it from the wrong place. If you reset the timer from a simple periodic interrupt that keeps firing regardless of whether the real work is alive, you've built a watchdog that faithfully reassures you while the device is frozen. It never expires, so it never saves you — it just hides the problem. The fix is to kick it only when genuine progress happens. A common pattern: each critical task reports that it has run recently, and the watchdog is kicked only when all of them have checked in. Now a single stuck task lets the timer expire, exactly as you want. A shared device layer is a natural home for this — one place that tracks every task's check-in instead of each task minding its own — which is part of what I build into EmbedIQ, my open framework for embedded and edge.

▸ First principle. A watchdog is only worth having if it can tell working from merely running.

Sources

The mechanisms here — hardware watchdog timers, the "kick/pet/feed" pattern, forced reset on expiry, windowed watchdogs, and per-task check-in before kicking — are standard embedded practice, described in essentially every microcontroller reference manual and in guidance such as the Memfault Interrupt writeup on watchdog best practices. This piece is method and lived experience; it contains no product performance figures.

FAQ

What is a hardware watchdog timer?
It's a hardware timer, independent of the CPU's normal code, that counts down and forces a reset if it isn't periodically reset ("kicked") by the firmware. It exists to recover a device that has hung, since a hung device won't recover on its own.

Why is a hung device worse than a crashed one?
A crash faults and reboots, so it self-corrects. A hang leaves the device powered and connected but stuck doing nothing — it reads as "up" to monitoring while being dead to the user. Nothing faults, so nothing reboots it, and the failure can persist unnoticed until a customer reports it.

What does it mean to "kick" or "feed" the watchdog?
It means periodically resetting the watchdog's countdown from firmware to signal "I'm still working." As long as the firmware keeps kicking in time, the timer never expires. If it hangs and stops kicking, the timer runs out and resets the chip.

Why shouldn't you kick the watchdog from a timer interrupt?
Because a periodic interrupt keeps firing even if the real application has hung, so it would kick the watchdog forever and hide the freeze. Kick it only when genuine progress happens — for example, after every critical task has checked in — so a stuck task actually lets the watchdog expire.

This is an embedded field note. If a device of yours has ever gone "online but doing nothing," the longer story and how I work live on my profile. — Ritesh | ritzylab.com