Watchdog timers — purpose, feeding, types: Visual walkthrough

This is the visual walkthrough of the watchdog timer. We build the timeout formula from a bare counter — no formula assumed — and watch, picture by picture, exactly what "feeding the dog" does to the count. By the end you will be able to draw why a watchdog resets a hung system, and why a window watchdog also catches one running too fast.

Step 1 — A counter is just a number that falls

WHAT. Start with the only piece of hardware that matters: a register (a small box that holds a whole number) that decreases by exactly $1$ on every tick of a clock. Call the number it holds $N$ . At the very start it is loaded with its biggest possible value, which we name $N_{ma x}$ .

WHY. Before we can talk about time, we must agree on the raw mechanism. There is no "timer" yet — only counting down. Time is something we will earn in Step 3 by attaching a clock to this falling number.

PICTURE. The red staircase is the number $N$ . Each step down is one clock tick. It starts high at $N_{ma x}$ and marches toward the black floor at $0$ .

Figure — Watchdog timers — purpose, feeding, types

Why $65535$ ? A 16-bit box holds $16$ binary digits. The largest number sixteen 1-bits can spell is $2^{16} - 1 = 65535$ . That is simply the tallest the staircase can be.

Step 2 — Hitting the floor is the reset

WHAT. Add one rule: the instant $N$ reaches $0$ , the hardware yanks a reset line and the whole chip reboots (or fires an interrupt, depending on config — see System Reset Sources).

WHY. This is the entire point of a watchdog. The falling number is a promise: "if nobody stops me, I will reboot you." We need this rule on the table before we can talk about stopping it.

PICTURE. Follow the red line down. Where it touches the black floor, a red bolt fires — that is the reset event. The counter cannot go below zero; zero is the trigger.

Step 3 — Attaching a clock turns ticks into seconds

WHAT. So far a "tick" is abstract. Now feed the counter a real clock of frequency $f_{c l oc k}$ — meaning $f_{c l oc k}$ ticks happen every second. One tick therefore lasts $1/ f_{c l oc k}$ seconds.

WHY. We chose to introduce frequency (ticks-per-second) here — and not, say, a stopwatch — because the hardware genuinely is driven by an oscillator ticking at a fixed rate. Frequency is the natural bridge: it converts "how many steps" into "how many seconds," which is the quantity we ultimately care about.

PICTURE. Same staircase, but now each step is labelled with its duration $Δ t = 1/ f_{c l oc k}$ . Widening or narrowing that step width is the only way to change how long the whole descent takes.

Step 4 — The prescaler stretches each step

WHAT. Real watchdogs insert a prescaler $P$ : a divider that only lets the counter step down once every $P$ raw clock ticks. So the effective tick rate is $f_{d i v i d e d} = f_{c l oc k} / P$ , and each visible step now lasts $P$ times longer.

WHY. With a fast clock, a raw 16-bit descent might take only a few milliseconds — too short to be useful. We need a knob to slow the fall. The prescaler is that knob. We introduce division (not multiplication) because we are slowing the counter: fewer usable ticks per second.

PICTURE. Two staircases side by side. Left: $P = 1$ , narrow steps, fast crash to the floor. Right (red): $P = 64$ , each step stretched $64 \times$ wider, so the same number of steps takes far longer to reach the floor.

Step 5 — Add up every step: the timeout formula

WHAT. To drain from $N_{ma x}$ to $0$ takes exactly $N_{ma x}$ steps, each lasting $Δ t$ . Multiply.

WHY. This is just "total time = number of steps × time per step." We already earned each factor: $N_{ma x}$ from Step 1, $Δ t$ from Step 4. Nothing new is assumed — we are only summing what we built.

PICTURE. The full red staircase from top to floor, with a bracket spanning the whole height labelled $N_{ma x}$ steps, and a bracket along the base labelled $T_{t im eo u t}$ — the total wall-clock time of the descent.

Step 6 — Feeding is "shove the number back to the top"

WHAT. "Feeding the dog" (wdt_reset()) does exactly one thing: reload $N$ back to $N_{ma x}$ . In pictures, it teleports the red dot from wherever it fell straight back up to the ceiling.

WHY. This is why the system survives. As long as software revisits the feed instruction before the descent completes, the counter never reaches $0$ , so the reset of Step 2 never fires. Health = "I keep making it back to the ceiling in time."

PICTURE. A sawtooth: the red line falls, then jumps vertically back to $N_{ma x}$ at each feed, falls again, jumps again — a healthy heartbeat that never touches the floor.

Step 7 — Degenerate case: the hang

WHAT. Now let the software freeze — stuck in an infinite loop, or blocked forever. The feed instruction is never reached, so no jump happens. The red line simply falls uninterrupted to the floor.

WHY. We must show the failure explicitly, because this is the scenario the watchdog exists to catch (see Fault Tolerance and Safe State Design). Without a feed, Steps 1–5 play out unmodified: full descent, then reset.

PICTURE. Healthy sawtooth on the left; at the moment of the hang the jumps stop, the line coasts down to the black floor, and the red reset bolt fires exactly $T_{t im eo u t}$ after the last successful feed.

Step 8 — The window watchdog: a floor and a ceiling-guard

WHAT. A plain watchdog only cares that you feed before the floor. A window watchdog adds a forbidden early zone: feeding is only legal once the counter has fallen below an upper threshold. Feed too early (counter still high) → reset. Feed too late (counter hit floor) → reset. Legal feeds live in a middle band.

WHY. A hung system is "too slow," but a runaway one — interrupt storm, a timing bug firing the loop $8 \times$ too fast — is "too fast," and a plain watchdog happily accepts those extra early feeds as healthy. The lower bound of the window is a second net that catches speed faults a normal dog is blind to.

PICTURE. The staircase now has two horizontal red guides: an upper threshold and the floor. Between them is the shaded legal window. A feed arrow landing above the upper line (too early) triggers reset; one landing inside the band is accepted; one that never comes lets the line hit the floor.

The one-picture summary

Everything on one canvas: the red counter falls at rate $P / f_{c l oc k}$ (Steps 3–4); the full drop from $N_{ma x}$ to $0$ takes $T_{t im eo u t}$ (Step 5); feeds teleport it back up (Step 6); a missed feed lets it hit the floor and reboot (Step 7); and the shaded band shows the window watchdog's legal feed zone bounded by $T_{min}$ and $T_{ma x}$ (Step 8).

Recall Feynman retelling — say it back in plain words

There's a number in a little box that counts down all by itself, one step at a time. How fast it steps is set by the clock and a stretch-knob called the prescaler; how far it has to fall is set by how big the number started. Multiply "how many steps" by "how long each step takes" and you get the timeout — the time until it hits zero and reboots the chip. Your software's whole job is to reach into the box every so often and shove the number back to the top; that's "feeding." Keep feeding and it never hits zero, so the chip keeps running — that's the heartbeat sawtooth. Stop feeding, because the code froze, and the number coasts down to zero and reboots you — that's the safety net. A fancier "window" version adds a rule that you're not even allowed to feed until the number has fallen part-way down, so software that's running way too fast gets caught too, not just software that's stuck.

Recall Quick self-test

Timeout for 16-bit counter, 128 kHz clock, prescaler 64 ::: $\frac{65535 \times 64}{128000} \approx 32.77$ s What physically happens on wdt_reset() ::: The counter register is reloaded to $N_{ma x}$ — the red dot jumps back to the ceiling. Why does a window watchdog have a lower time bound ::: To catch code running too fast (early feeds), which a plain watchdog accepts as healthy. After a hang, how long until reset ::: Up to one full $T_{t im eo u t}$ , measured from the last successful feed.

See also: Hardware Timer Peripherals · Real-Time Operating Systems · Brown-Out Detection · Bootloader Design