Worked examples — Watchdog timers — purpose, feeding, types

This page is the "no case left behind" companion to the parent watchdog note. Before we begin, let us re-earn the one formula that everything below leans on, so no symbol arrives unexplained.

Figure 1 turns this into a picture: watch the blue line ramp down from $N_{max}$, and see each yellow dot snap it back to the top — that snap is a "feed". The red dashed line at zero is where a reset fires.

---

The scenario matrix

Every question a watchdog topic can throw at you lives in one of these cells. The examples afterward each announce which cell they fill.

Cell	Case class	What is being tested
A	Plain timeout, given all values	Direct use of the formula
B	Solve backwards for the prescaler	Pick $P$ to hit a target $T$
C	8-bit vs 16-bit counter (small $N_{max}$)	Effect of counter width
D	Zero / degenerate input ($P=1$, or "never fed")	Limiting behaviour, sanity edges
E	Feed-margin: does the loop finish in time?	Worst-case loop timing
F	Too-late fault (a hang)	Regular WDT catches slow/frozen code
G	Too-early fault (window WDT)	Window WDT catches fast/runaway code
H	Real-world word problem	Choosing timeout for a real device
I	Exam twist (interrupt storm looks "healthy")	Why a window is needed

---

Worked examples

Example 1 — Cell A: plain timeout

Forecast: guess first — will it be milliseconds, seconds, or minutes? Jot it down.

1. Write $f_{clock}$ in Hz. $128\text{kHz}=128000\text{Hz}$. Why this step? The formula needs pulses-per-second, and "k" hides a factor of $1000$; keeping units clean prevents 1000× errors.
2. Plug in. $T=\frac{65535}{128000}\times 64$ (recall $T\equiv T_{timeout}$). Why this step? Direct application — every symbol is known.
3. Arithmetic. $\frac{65535}{128000}=0.51199$ s per full count at $P=1$; times $64$ gives $32.77$ s. Why this step? Splitting it shows the middle number ($0.512$ s) is the "no-prescaler" timeout, which we reuse later.

$T_{timeout}=\frac{65535}{128000}\times 64=32.77\text{s}$

Verify: Units — $\frac{\text{count}}{\text{count/s}}\times (\text{dimensionless})=\text{s}$. ✓ Order of magnitude: tens of seconds, matching the parent note's number for $P=64$.

---

Example 2 — Cell B: solve backwards for the prescaler

Forecast: guess whether you need a small or large $P$.

1. Rearrange the formula for $P$. From $T=\frac{N_{max}}{f_{clock}}P$, isolate $P=\frac{T{f}_{clock}}{N_{max}}$. Why this step? We know the answer $T$ and want the knob $P$ — so put $P$ alone.
2. Plug the target. $P=\frac{0.5\times 128000}{65535}=\frac{64000}{65535}=0.976$. Why this step? This ideal $P$ is what you'd need if prescalers were continuous.
3. Snap to the fixed menu. $0.976$ is nearest to $1$. Why this step? Hardware only offers the discrete menu defined above; you must round to a value that physically exists.
4. Check the real timeout at $P=1$. $T=\frac{65535}{128000}\times 1=0.512\text{s}=512\text{ms}$. Why this step? The delivered timeout, not the ideal one, is what actually protects you.

Verify: $512\text{ms}$ is within $2.4\%$ of the $500\text{ms}$ target — the closest any menu prescaler gets. ✓

---

Example 3 — Cell C: 8-bit vs 16-bit counter

Forecast: will the 8-bit version be shorter or longer, and by roughly what factor?

1. 8-bit timeout. $T_8=\frac{255}{1000000}\times 256=0.06528\text{s}=65.28\text{ms}$. Why this step? Direct formula with the small $N_{max}$.
2. 16-bit timeout, same knobs. $T_{16}=\frac{65535}{1000000}\times 256=16.777\text{s}$. Why this step? Isolate the only thing that changed — the counter width.
3. Ratio. $\frac{T_{16}}{T_8}=\frac{65535}{255}=257.0$. Why this step? Shows counter width scales timeout linearly — a wider counter buys hundreds of times more patience.

Verify: $65535/255=257$ exactly (since $65535=255\times 257$). ✓ A narrow counter forces you to either feed very often or use a huge prescaler.

---

Example 4 — Cell D: degenerate inputs & limits

Forecast: guess the shortest timeout and what happens if you never feed.

1. $P=1$ is the no-divide limit. $T=\frac{65535}{128000}\times 1=0.512\text{s}$. Why this step? $P=1$ passes every clock pulse — no slowing — so it is the floor of the timeout range for this hardware.
2. Interpret "never fed". The counter simply runs $65535\to 0$ once, uninterrupted, then triggers a reset. Why this step? A watchdog that is enabled but never fed is guaranteed to fire after exactly one timeout — this is the dead-man's-switch limit.
3. Degenerate case $P=0$? Illegal — no such prescaler exists on the menu; dividing clock by $0$ is meaningless. Why this step? Cover the invalid input so the reader never expects it. Hardware simply won't offer $P=0$.

Verify: Shortest timeout $512\text{ms}$ equals the $P=1$ row of Example 1's split. ✓ Consistency across examples confirms the formula.

---

Example 5 — Cell E: feed-margin timing

Forecast: guess the margin in ms, then guess yes/no for the doubling.

1. Worst-case time between feeds = full loop. $t_{loop}=50+100+50=200\text{ms}$. Why this step? Because we feed only after the loop (see the parent's [!mistake] on feeding too early), the gap between two feeds is one whole loop.
2. Margin. $M=T_{timeout}-t_{loop}=500-200=300\text{ms}$. Why this step? Margin is the slack before a legitimate slow loop trips the dog. Positive margin = safe.
3. Answer the doubling question directly. Double the $100\text{ms}$ task → new loop $=50+200+50=300\text{ms}$. Compare to timeout: $300<500$, so yes, it is still safe, with a new margin of $500-300=200\text{ms}$. Why this step? The question asked a specific 2× scenario, so we compute that exact case rather than a general bound.
4. How far could that task grow before trouble? The fixed tasks eat $50+50=100\text{ms}$, leaving $500-100=400\text{ms}$ for the middle task — so it could grow from $100\text{ms}$ up to $400\text{ms}$ (a 4× blow-up) before touching the timeout edge. Why this step? Frames the 2× answer inside the full safe range, so the reader sees both the specific case and its headroom.

Figure 2 shows this as a bar: the blue chunk is the loop, the green chunk is the margin, and the red dashed line is the timeout the two together must not cross.

Verify: $200+300=500=T_{timeout}$ ✓. Doubled loop $50+200+50=300<500$ → safe ✓. Max middle-task length $=500-100=400\text{ms}$ ✓.

---

Example 6 — Cell F: a "too-late" fault (a hang)

Let $t_0$ = the time of the last successful feed (the last moment the counter was reloaded to $N_{max}$). Every timing below is measured from $t_0$.

Forecast: guess how many ms after the hang starts the reset happens.

1. Last good feed. Iteration 6 finished and fed at $t_0$. The counter reloads to $N_{max}$. Why this step? The reset clock starts from the last successful feed $t_0$, not from the hang.
2. Counter free-runs. With no more feeds, the counter marches $N_{max}\to 0$, taking the full $T_{timeout}=500\text{ms}$. Why this step? A hang = feeding stopped = the never-fed limit of Example 4 kicks in.
3. Reset instant. Reset fires at $t_0+500\text{ms}$. The dead time (from hang start, which is $\le 200\text{ms}$ after $t_0$) is at most $500\text{ms}$. Why this step? Gives the guaranteed upper bound on downtime — the number a safety engineer cares about.

Figure 3: the green vertical lines are healthy feeds up to $t_0$; the red band is the hang with no feeds; the red dashed line marks the reset at $t_0+500\text{ms}$.

Verify: Dead time $\le T_{timeout}=500\text{ms}$ ✓. If the hang starts right after a feed, worst-case downtime = $500\text{ms}$; if late in the loop, less. The dog always recovers within one timeout.

---

Example 7 — Cell G: a "too-early" fault (window watchdog)

A window watchdog accepts a feed only inside a time window. Define, measured since the previous feed:

• $T_{min}$ — the earliest legal feed time. Feeding before $T_{min}$ is a fault (code running too fast).
• $T_{max}$ — the latest legal feed time. Feeding after $T_{max}$ is a fault (code hung, like a plain dog).
• $T_{feed}$ — the actual time, since the last feed, at which this feed occurs.

The rule is $T_{min}<T_{feed}<T_{max}$. In this example the hardware is set so $T_{min}=60\text{ms}$ and $T_{max}=80\text{ms}$.

Forecast: legal or reset? And which bound is violated?

1. Compare against the lower bound. $T_{feed}=40\text{ms}$, and $T_{min}=60\text{ms}$. Since $40<60$, we feed too early. Why this step? A window watchdog has two comparators; the early feed fails the "not before $T_{min}$" test.
2. Result. Feeding before $T_{min}$ is treated as a fault → reset. Why this step? The whole point of the lower bound: code running too fast (an interrupt storm, a runaway loop) is as broken as code frozen.
3. Why a plain watchdog misses it. A plain dog only checks $T_{feed}<T_{max}$. Since $40<80$, it would happily accept the fast feed and see "healthy". No upper-only dog can detect early. Why this step? Names exactly the gap the window fills — a regular WDT has no lower bound at all.

Figure 4 shades the timeline into three zones since the last feed: a red "too early" zone below $T_{min}$, a green "OK window" between the bounds, and a red "too late" zone above $T_{max}$. The yellow dot at $40\text{ms}$ lands in the red early zone.

Verify: $40<60=T_{min}$ → out of window → reset ✓. A plain dog with only $T_{max}=80$: $40<80$ → accepted, bug hidden ✓ (proving the window is necessary).

---

Example 8 — Cell G/D limit: right on the boundary

Forecast: are the endpoints inside or outside?

1. Interpret strict inequalities. The bounds are strict ($<$, not $\le$): the open interval $(60,80)$. Why this step? Boundary behaviour is a classic degenerate case — "exactly on the edge" must be pinned down.
2. Test each. $60$: fails ($60\ngtr 60$). $70$: safe ($60<70<80$). $80$: fails ($80\nless 80$). Why this step? Applies the two comparators literally at the edges.
3. Design lesson. Aim for the centre ($70\text{ms}$), never the edge, so clock jitter of a few ms can't push you out. Why this step? Real clocks drift; margin on both sides is the safe target.

Verify: Only $70\text{ms}$ satisfies $60<T_{feed}<80$ ✓; both endpoints are excluded by the strict inequalities ✓.

---

Example 9 — Cell H: real-world word problem

Forecast: guess which menu prescaler wins.

1. Set the requirement. Need $T>4\text{s}$ (one cycle) with slack for the $2.5\text{s}$ transmit — target roughly $6\text{–}20\text{s}$: long enough to never false-trip, short enough to recover quickly. Why this step? The timeout must exceed the longest legitimate time between feeds, or valid long operations trip false resets.
2. Compute the base ($P=1$) timeout once. $T_1=\frac{65535}{32768}=2.0\text{s}$. Why this step? Every menu value is just this base scaled by $P$, so computing it once lets us read off all others by multiplying.
3. Scan the menu by multiplying $T_1$ by $P$.
   • $P=1$: $2.0\text{s}$ — smaller than the $2.5\text{s}$ transmit → false resets. Reject.
   • $P=8$: $2.0\times 8=16.0\text{s}$ — comfortably above $4\text{s}$ and above $2.5\text{s}$; recovers in a sane time. Accept.
   • $P=64$: $2.0\times 64=128\text{s}$ — over two minutes to recover from a hang; needlessly slow. Reject. Why this step? Walking the menu shows $P=8$ is the smallest prescaler that clears both legitimate operations, giving the fastest safe recovery.
4. State the chosen timeout. With $P=8$: $T=\frac{65535}{32768}\times 8=16.0\text{s}$. Why this step? The final deliverable — the number you actually program into the device.

Verify: $P=8$ gives $16.0\text{s}>4\text{s}$ ✓ and $>2.5\text{s}$ transmit ✓; $P=1$ gives $2.0\text{s}<2.5\text{s}$ → correctly rejected ✓; $P=64$ gives $128\text{s}$, over-long ✓. See Fault Tolerance and Safe State Design for what the device should do after such a reset.

---

Example 10 — Cell I: the exam twist (interrupt storm "looks healthy")

Forecast: guess the feed count in $80\text{ms}$.

1. Count feeds. One feed per $10\text{ms}$, so in an $80\text{ms}$ span: $80/10=8$ feeds. Why this step? Frequency of feeding tells us how the dog "sees" system health.
2. Why it looks healthy to a plain dog. Each feed happens well before $T_{max}=80\text{ms}$, so the counter never reaches zero. The plain dog reports "alive" — even though the timing is $7\times$ too fast. Why this step? Exposes the blind spot: a plain dog answers "is it running?" not "is it running at the right rate?"
3. Window dog reaction. With window $60<T_{feed}<80$ (so $T_{min}=60\text{ms}$), a feed at $T_{feed}=10\text{ms}$ violates the lower bound ($10<60$) → reset on the very first fast feed, forcing you to find the timing bug. Why this step? Directly contrasts the two watchdog types on the exact failure a regular dog cannot see. This is the "why windows exist" punchline.
4. Resolution. The system reboots on the storm, enters its safe state, and the developer sees a reset traceable to the too-early feed — the timing bug is now visible and fixable rather than silently corrupting behaviour. This is precisely the case a plain watchdog would have masked; see also Real-Time Operating Systems where feed timing is scheduled per task. Why this step? Closes the scenario: not just "reset happens" but "the bug becomes diagnosable", which is the whole payoff of Cell I.

Verify: $80/10=8$ feeds ✓; $10<60=T_{min}$ → window dog resets ✓; $10<80=T_{max}$ → plain dog accepts, bug hidden ✓.

---

Recall Quick self-test

Timeout for $N_{max}=65535$, $f=128\text{kHz}$, $P=64$? ::: $32.77\text{s}$ Smallest menu prescaler to get near $500\text{ms}$ at $128\text{kHz}$, 16-bit? ::: $P=1$, giving $512\text{ms}$ Ratio of 16-bit to 8-bit timeout at equal clock and prescaler? ::: exactly $257$ Worst-case downtime for a hang with a $500\text{ms}$ dog? ::: $\le 500\text{ms}$ (one full timeout) If the $100\text{ms}$ middle task doubles to $200\text{ms}$ under a $500\text{ms}$ dog, safe? ::: yes — loop becomes $300\text{ms}<500\text{ms}$ Which watchdog catches a feed that comes too early? ::: the window watchdog (lower bound $T_{min}$) Feeds in $80\text{ms}$ if an ISR feeds every $10\text{ms}$? ::: $8$ — and a plain dog sees it as "healthy"