Exercises — Watchdog timers — purpose, feeding, types

Answer: (b). The defining behaviour is the dead-man's-switch idea from the parent note: software must keep proving it is alive by feeding the timer. If feeding stops, the counter reaches $0$ and forces a reset/interrupt.

• (a) describes a plain hardware timer — no automatic reset on neglect.
• (c) is Brown-Out Detection, a different reset source.
• (d) is just logging; it takes no action.

• Feed ::: The act of software reloading the counter back to $N_{max}$ so it never reaches $0$ (on AVR this is the wdr instruction, i.e. wdt_reset()).
• Timeout ::: The time it takes the counter to fall from $N_{max}$ to $0$ with no feeding — the deadline software must beat.
• Prescaler ::: A clock divider that slows the counter so each decrement takes longer, letting a small counter measure a long time.

Plug straight into the formula. $T_{timeout}=\frac{255}{32768}\times 128=\frac{32640}{32768}\approx 0.99609\text{s}\approx 996\text{ms}$ So this configuration times out in about 996 ms — just under one second. Look at figure s01: same staircase idea, just $255$ steps instead of $65535$.

Rearrange the formula to solve for the unknown — why rearrange? Because the timeout is the given here and the prescaler is what we must pick. Here $T_{target}=0.5\text{s}$ is the timeout we want. $\text{prescaler}=\frac{T_{target}\times f_{clock}}{N_{max}}=\frac{0.5\times 1,000,000}{65535}=\frac{500,000}{65535}\approx 7.63$ The nearest standard prescaler is $8$. With $\text{prescaler}=8$ the real timeout becomes $T_{timeout}=\frac{65535}{1,000,000}\times 8=0.52428\text{s}\approx 524\text{ms}$ A hair over 500 ms — safe, since a slightly longer window never causes a false reset; it only relaxes the deadline.

One full loop takes $50+100+50=200\text{ms}$. That is the longest gap between two feeds in healthy operation, so $T_{loop}=200\text{ms}$. $\text{margin}=T_{timeout}-T_{loop}=500-200=300\text{ms}$ $\text{fraction used}=\frac{T_{loop}}{T_{timeout}}=\frac{200}{500}=0.4=40\%$ A healthy $40\%$ utilisation leaves comfortable headroom. Figure s02 shows the feed happening at $200$ ms against the $500$ ms deadline bar.

Compute both timeouts ($T_A$, $T_B$ are just each config's $T_{timeout}$). $T_A=\frac{65535}{128000}\times 64=0.51199\times 64\approx 32.77\text{s}$ $T_B=\frac{65535}{128000}\times 1024=0.51199\times 1024\approx 524.28\text{s}$ The update needs the watchdog to stay quiet for $40\text{s}$.

• Dev A ($32.77\text{s}<40\text{s}$): the watchdog fires mid-update → false reset, possibly corrupting the flash write (a job for careful Bootloader Design).
• Dev B ($524.28\text{s}>40\text{s}$): survives the update comfortably.

The analysis takeaway: timeout must exceed the longest legitimate uninterrupted operation, or you get false positives. Short timeouts recover faster from real hangs but are less tolerant of long valid work — a genuine trade-off.

Because the counter drops one unit per millisecond from $63$, its value at whole millisecond $t$ is $Counter(t)=63-t(t=0,1,2,\dots ).$ Earliest legal feed ($T_{min}$). We need $Counter(t)\le 55$. Solve $63-t\le 55\Rightarrow t\ge 8$. At $t=8$ the counter is exactly $55$, which the rule declares legal ("$55$ or below"). So the earliest legal feed is $T_{min}=8\text{ms}.$ (If the chip instead required strictly below $55$, the first legal instant would be the next step, $t=9$ ms, because at $t=8$ the counter still reads $55$. We adopt the "$\le$" rule stated above.)

Latest safe feed ($T_{max}$). Reset fires the instant $Counter(t)\le 40$, i.e. at $63-t\le 40\Rightarrow t\ge 23$. So $t=23$ ms is already a reset — too late. The last safe whole-millisecond feed is therefore one step earlier, when the counter still reads $41$: $T_{max}=22\text{ms}(\text{counter}=63-22=41>40).$ Legal window: feed at any whole millisecond $t$ with $8\le t\le 22$ ms (counter from $55$ down to $41$) — a $15$-step-wide slot. Figure s03 draws this band and labels the two boundary counter values.

Step 1 — target. Desired $T_{target}\approx 2\times 180=360\text{ms}$.

Step 2 — what prescaler lands near there? Solve the formula for the prescaler at the target: $\text{prescaler}=\frac{T_{target}\times f_{clock}}{N_{max}}=\frac{0.360\times 32768}{65535}=\frac{11796.5}{65535}\approx 0.18$ The smallest available prescaler is $1$, which gives the shortest possible timeout on this hardware. Name that best-case value $T_{fastest}$ (it is simply $T_{timeout}$ when $\text{prescaler}=1$): $T_{fastest}=\frac{65535}{32768}\times 1=1.99997\text{s}\approx 2.0\text{s}$ Step 3 — read the reality. Even the fastest configuration times out at $\approx 2.0\text{s}$, far above our $360\text{ms}$ wish. That is a feature of the hardware: with a slow $32.768$ kHz clock and a 16-bit counter, you cannot get a sub-second timeout. So we accept $\text{prescaler}=1$, $T_{timeout}\approx 2.0\text{s}$.

Step 4 — margin check. $\text{margin}=T_{timeout}-T_{loop}=1999.97-180\approx 1820\text{ms},\text{utilisation}=\frac{T_{loop}}{T_{timeout}}=\frac{180}{1999.97}\approx 9\%$ The loop uses only $\approx 9\%$ of the window — extremely safe, no false resets, and a true hang still recovers in $\le 2\text{s}$. Synthesis lesson: sometimes the "ideal" timeout $T_{target}$ is unreachable and the design job is choosing the closest feasible configuration, then verifying the margin is comfortable — which it is.

Corrected version — feed after a full successful iteration:

void loop() {
    read_sensor();
    if (compute() < 0) {
        enter_safe_state();   // deliberate, then let WDT reset us
        while (1) { }         // no feed here -> WDT recovers
    }
    actuate();
    wdt_reset();              // heartbeat: only if we reached the end
}

What it now catches: any path that fails to complete the entire loop body — including the deliberate error-spin — because the feed only happens once read_sensor → compute → actuate all succeed. In the buggy original, the early feed gave the error-spin a full fresh timeout before recovery, and an accidental infinite loop after the feed would still be masked for one whole window. See Safe State Design for why we drive outputs to a known-safe value before letting the reset happen, and Fault Tolerance for the recovery philosophy.

(a) The ISR fires at $t=10,20,30,40,50,60,70,80\text{ms}$ after the last successful refresh. A feed is legal only when $60<t<80$ (strictly inside).

• $t=10,20,30,40,50\text{ms}$: too early ($t<60$) → each is rejected / triggers a reset on a strict window watchdog.
• $t=60\text{ms}$: on the boundary, and $60<60$ is false → too early, not legal.
• $t=70\text{ms}$: $60<70<80$ → legal ✅ — the only one.
• $t=80\text{ms}$: boundary, $80<80$ is false → too late.

Final count: exactly 1 legal feed (at $t=70\text{ms}$) out of the 8 attempts. Every other attempt is a window violation, so the window watchdog refuses the early feeds and forces you to confront the $10\text{ms}$ timing bug.

(b) A plain watchdog only asks "were you fed before $T_{max}$?" Feeding every $10\text{ms}$ satisfies that easily — 8 healthy-looking heartbeats inside every $80\text{ms}$ span — so the timing bug is completely invisible to it. The window watchdog adds the lower bound $T_{min}$, converting the question into "were you fed at the RIGHT rate?" (not too fast, not too slow). That is exactly what catches interrupt storms and skipped-delay bugs that a plain watchdog sails past. Cross-reference Interrupt Service Routines for why keeping ISRs short and rate-correct matters, and Real-Time Operating Systems for how an RTOS task-based watchdog generalises this to per-task heartbeats.

The supervisor can only feed once all three bits are set, then it clears them. After clearing, the next feed cannot happen until every task has completed at least one more cycle — and the slowest task, C, gates that, because A and B set their bits far more often and are already set well before C finishes.

• Worst-case gap between two supervisor feeds $=$ Task C's period $=100\text{ms}$ (plus a little scheduling jitter).
• Therefore the hardware timeout must satisfy $T_{timeout}>100\text{ms}+\text{jitter margin}.$ Choosing $T_{timeout}\approx 2\times 100=200\text{ms}$ gives a $100\%$ margin over the slowest heartbeat while still recovering a genuine total hang within $200\text{ms}$. Mastery point: in a multi-task system the watchdog is only as fast as your slowest mandatory heartbeat — set the timeout from that task, not from the fast ones, or a stalled Task C will look healthy whenever A and B keep the shared feed alive. That AND-gate on the flags is what prevents a fast task from masking a dead slow task.

• Timeout formula: multiply by prescaler ::: $T_{timeout}=\frac{N_{max}}{f_{clock}}\times \text{prescaler}$ — bigger prescaler means longer timeout.
• Solve for prescaler ::: $\text{prescaler}=\frac{T_{target}{f}_{clock}}{N_{max}}$, then round to a standard value.
• Where to feed ::: once, at the end of a complete iteration (heartbeat), never first-thing, never per-function.
• Window watchdog ::: legal only in $T_{min}\le T_{feed}\le T_{max}$; "reset when counter $\le X$" means last safe step is $X+1$.
• Multi-task ::: gate the feed on the AND of all mandatory heartbeats; timeout set by the slowest task.