Watchdog timers — purpose, feeding, types: Exercises

5.5.23 · D4 · Coding › Embedded Systems & Real-Time Software › Watchdog timers — purpose, feeding, types

Yeh page watchdog timer topic ke liye ek graded workout hai. Har problem ka full solution ek collapsible callout ke andar chhupa hua hai taaki tum pehle khud try kar sako. Levels hain L1 Recognition → L2 Application → L3 Analysis → L4 Synthesis → L5 Mastery.

Shuru karne se pehle, ek promise: neeche use kiya gaya har symbol wahi hai jo tumne parent note mein already earn kiya hai. Hum sirf ek timeout equation pe rely karte hain, toh chaliye usse plain words mein re-anchor karte hain — aur apne symbols ek baar pin down karte hain taaki baad mein kuch bhi surprise na kare.

Formula Woh ek formula jo hum baar baar use karte hain

Ek watchdog basically ek down-counter hai jo ek slowed-down clock pe tick karta hai. Apni top value $N_{ma x}$ se shuru hokar yeh $0$ tak count down karta hai. Isme jo time lagta hai woh hai timeout: $T_{t im eo u t} = \frac{N _{ma x}}{f _{c l oc k}} \times prescaler$

$N_{ma x}$ = woh sabse bada number jo counter hold kar sakta hai (ek 16-bit counter $65535$ par top out karta hai; ek 8-bit counter $255$ par).
$f_{c l oc k}$ = clock slowing se pehle har second mein kitne ticks deliver karta hai.
$prescaler$ = woh divider jo clock ko slow karta hai (ab har tick $prescaler$ raw cycles leta hai).

Yeh shape kyun? Har $\frac{prescaler}{f _{c l oc k}}$ seconds mein ek decrement hoti hai. Decrements ki count $N_{ma x}$ se multiply karo aur tumhe total fall time mil jaata hai. Figure s01 dekho — staircase woh counter hai jo gir raha hai, aur poori staircase ki width $T_{t im eo u t}$ hai.

Figure — Watchdog timers — purpose, feeding, types

Prerequisite links agar koi step shaky lage: Hardware Timer Peripherals, Interrupt Service Routines, System Reset Sources, Real-Time Operating Systems, Fault Tolerance, Brown-Out Detection, Safe State Design, Bootloader Design.

L1 — Recognition

Problem 1 (L1)

Ek watchdog timer ko inme se kaunse se best describe kiya jaata hai?

(a) Ek stopwatch jo CPU tasks schedule karne ke liye read karta hai. (b) Ek hardware down-counter jo system ko reset ya interrupt karta hai agar software periodically use "feed" karna fail kare. (c) Ek voltage sensor jo low battery detect karta hai. (d) Ek memory region jo last error code store karta hai.

Recall Solution

Answer: (b). Defining behaviour woh dead-man's-switch idea hai jo parent note se aaya hai: software ko timer feed karke yeh prove karte rehna hota hai ki woh alive hai. Agar feeding ruk jaaye, toh counter $0$ tak pahunch jaata hai aur reset/interrupt force karta hai.

(a) ek plain hardware timer describe karta hai — neglect hone par koi automatic reset nahi.
(c) Brown-Out Detection hai, ek alag reset source.
(d) sirf logging hai; yeh koi action nahi leta.

Problem 2 (L1)

Har term ko uske meaning se match karo: feed, timeout, prescaler.

Recall Solution

Feed ::: Software ka woh act jisme counter ko wapas $N_{ma x}$ par reload kiya jaata hai taaki woh kabhi $0$ tak na pahunche (AVR par yeh wdr instruction hai, yani wdt_reset()).
Timeout ::: Woh time jo counter ko $N_{ma x}$ se $0$ tak girne mein lagta hai jab koi feeding na ho — woh deadline jise software ko beat karna hota hai.
Prescaler ::: Ek clock divider jo counter ko slow karta hai taaki har decrement zyada time le, jisse ek chhota counter badi time measure kar sake.

L2 — Application

Problem 3 (L2)

Ek 8-bit watchdog counter ( $N_{ma x} = 255$ ) $f_{c l oc k} = 32768 Hz$ par $prescaler = 128$ ke saath clock kiya jaata hai. Timeout period milliseconds mein nikalo.

Recall Solution

Seedha formula mein plug karo. $T_{t im eo u t} = \frac{255}{32768} \times 128 = \frac{32640}{32768} \approx 0.99609 s \approx 996 ms$ Toh yeh configuration lagbhag 996 ms mein — yaani ek second se thoda kam — timeout hoti hai. Figure s01 dekho: same staircase idea, bas $65535$ ki jagah $255$ steps.

Problem 4 (L2)

Tumhe $N_{ma x} = 65535$ aur $f_{c l oc k} = 1000000 Hz$ (1 MHz) wale WDT par 500 ms ka timeout chahiye. Tumhe kaunsi prescaler value chahiye? Kya yeh ek "typical" prescaler (1, 8, 64, 256, 1024) hai?

Recall Solution

Unknown solve karne ke liye formula rearrange karo — rearrange kyun? Kyunki yahan timeout given hai aur prescaler woh hai jo hume pick karna hai. Yahan $T_{t a r g e t} = 0.5 s$ woh timeout hai jo hum chahte hain. $prescaler = \frac{T _{t a r g e t} \times f _{c l oc k}}{N _{ma x}} = \frac{0.5 \times 1 , 000 , 000}{65535} = \frac{500 , 000}{65535} \approx 7.63$ Nearest standard prescaler $8$ hai. $prescaler = 8$ ke saath real timeout ban jaata hai $T_{t im eo u t} = \frac{65535}{1 , 000 , 000} \times 8 = 0.52428 s \approx 524 ms$ 500 ms se thoda zyada — safe hai, kyunki thoda lamba window kabhi false reset cause nahi karta; yeh sirf deadline relax karta hai.

Problem 5 (L2)

Ek main loop teen tasks run karta hai jinhe $50$ ms, $100$ ms, aur $50$ ms lagte hain, phir har iteration mein ek baar watchdog feed karta hai. Watchdog timeout $500$ ms hai. Margin (spare time) kya hai jisse pehle ek hang reset trip karta, aur loop timeout ka kitna fraction use karta hai?

Recall Solution

Ek full loop mein $50 + 100 + 50 = 200 ms$ lagta hai. Healthy operation mein do feeds ke beech ka yeh sabse lamba gap hai, toh $T_{l oo p} = 200 ms$ . $margin = T_{t im eo u t} - T_{l oo p} = 500 - 200 = 300 ms$ $fraction used = \frac{T _{l oo p}}{T _{t im eo u t}} = \frac{200}{500} = 0.4 = 40%$ Healthy $40%$ utilisation comfortable headroom deta hai. Figure s02 mein feed $200$ ms par hoti dikhti hai, $500$ ms deadline bar ke against.

L3 — Analysis

Problem 6 (L3)

Do developers same 16-bit WDT ( $N_{ma x} = 65535$ , $f_{c l oc k} = 128000 Hz$ ) configure karte hain.

Dev A $prescaler = 64$ pick karta hai.
Dev B $prescaler = 1024$ pick karta hai.

Ek legitimate firmware-update routine 40 seconds leti hai jiske dauran watchdog feed nahi kiya ja sakta. Kaunse developer ki configuration false reset cause karti hai, aur kyun?

Recall Solution

Dono timeouts compute karo ( $T_{A}$ , $T_{B}$ bas har config ka $T_{t im eo u t}$ hai). $T_{A} = \frac{65535}{128000} \times 64 = 0.51199 \times 64 \approx 32.77 s$ $T_{B} = \frac{65535}{128000} \times 1024 = 0.51199 \times 1024 \approx 524.28 s$ Update ko $40 s$ tak watchdog quiet rehne ki zaroorat hai.

Dev A ( $32.77 s < 40 s$ ): watchdog mid-update fire karta hai → false reset, possibly flash write corrupt karta hai (yeh careful Bootloader Design ka kaam hai).
Dev B ( $524.28 s > 40 s$ ): update comfortably survive karta hai.

Analysis takeaway: timeout sabse lamba legitimate uninterrupted operation se zyada hona chahiye, warna false positives milenge. Short timeouts real hangs se faster recover karte hain lekin lambe valid work ke liye less tolerant hote hain — yeh ek genuine trade-off hai.

Problem 7 (L3)

Ek STM32 par ek window watchdog ek 6-bit down-counter use karta hai jo $1$ decrement per millisecond ki effective rate par feed hota hai, $N_{ma x} = 63$ se shuru hokar. Chip ka rule (precisely stated taaki boundaries unambiguous rahen):

Feeding too early reject ki jaati hai jab tak counter upper threshold $T h r es h o l d_{u pp er} = 55$ se strictly greater ho. Feed tabhi legal hai jab counter $55$ ya neeche aa jaaye.
Chip reset immediately issue karta hai jab counter lower threshold $T h r es h o l d_{l o w er} = 40$ par pahunche (yani $\leq 40$ already "too late" hai).

$T_{min}$ (earliest legal feed time) aur $T_{ma x}$ (latest safe feed time) nikalo, last refresh se whole milliseconds mein measure karke. Dhyan raho counter discrete hai — yeh sirf integer milliseconds par integer values leta hai.

Recall Solution

Kyunki counter $63$ se har millisecond mein ek unit drop karta hai, whole millisecond $t$ par uski value hai $C o u n t er (t) = 63 - t (t = 0, 1, 2, \dots) .$ Earliest legal feed ( $T_{min}$ ). Hume $C o u n t er (t) \leq 55$ chahiye. Solve karo $63 - t \leq 55 \Rightarrow t \geq 8$ . $t = 8$ par counter exactly $55$ hai, jo rule ke hisaab se legal hai (" $55$ ya neeche"). Toh earliest legal feed hai $T_{min} = 8 ms .$ (Agar chip strictly $55$ se neeche maangta, toh pehla legal instant next step hota, $t = 9$ ms, kyunki $t = 8$ par counter abhi bhi $55$ read karta hai. Hum upar stated " $\leq$ " rule adopt karte hain.)

Latest safe feed ( $T_{ma x}$ ). Reset tab fire hoti hai jab $C o u n t er (t) \leq 40$ , yani $63 - t \leq 40 \Rightarrow t \geq 23$ par. Toh $t = 23$ ms already ek reset hai — too late. Isliye last safe whole-millisecond feed ek step pehle hai, jab counter abhi $41$ read karta hai: $T_{ma x} = 22 ms (counter = 63 - 22 = 41 > 40) .$ Legal window: kisi bhi whole millisecond $t$ par feed karo jahan $8 \leq t \leq 22$ ms (counter $55$ se $41$ tak) — ek $15$ -step-wide slot. Figure s03 yeh band draw karta hai aur dono boundary counter values label karta hai.

L4 — Synthesis

Problem 8 (L4)

Design goal: ek control loop ke liye WDT configuration choose karo.

Main loop, worst case, har iteration mein $T_{l oo p} = 180 ms$ leta hai (measured).
Tum chahte ho ki timeout roughly worst-case loop time ka 2× ho taaki ek single slow iteration kabhi false-reset na kare, lekin ek true hang ek fraction of a second mein recover ho jaaye. Is wish ko $T_{t a r g e t}$ kaho.
Hardware: $N_{ma x} = 65535$ , $f_{c l oc k} = 32768 Hz$ , standard prescalers ${1, 8, 64, 256, 1024}$ .

Prescaler pick karo, actual timeout $T_{t im eo u t}$ report karo, aur ek worst-case loop par safety margin confirm karo.

Recall Solution

Step 1 — target. Desired $T_{t a r g e t} \approx 2 \times 180 = 360 ms$ .

Step 2 — kaunsa prescaler wahan land karta hai? Target par prescaler ke liye formula solve karo: $prescaler = \frac{T _{t a r g e t} \times f _{c l oc k}}{N _{ma x}} = \frac{0.360 \times 32768}{65535} = \frac{11796.5}{65535} \approx 0.18$ Sabse chhota available prescaler $1$ hai, jo is hardware par sabse chhota possible timeout deta hai. Us best-case value ko $T_{f a s t es t}$ naam do (yeh simply $T_{t im eo u t}$ hai jab $prescaler = 1$ ): $T_{f a s t es t} = \frac{65535}{32768} \times 1 = 1.99997 s \approx 2.0 s$ Step 3 — reality padhna. Fastest configuration bhi $\approx 2.0 s$ par timeout hoti hai, hamare $360 ms$ wish se bahut upar. Yeh hardware ki ek feature hai: slow $32.768$ kHz clock aur 16-bit counter ke saath, tum sub-second timeout nahi pa sakte. Toh hum $prescaler = 1$ , $T_{t im eo u t} \approx 2.0 s$ accept karte hain.

Step 4 — margin check. $margin = T_{t im eo u t} - T_{l oo p} = 1999.97 - 180 \approx 1820 ms, utilisation = \frac{T _{l oo p}}{T _{t im eo u t}} = \frac{180}{1999.97} \approx 9%$ Loop sirf window ka $\approx 9%$ use karta hai — extremely safe, koi false resets nahi, aur ek true hang abhi bhi $\leq 2 s$ mein recover hoga. Synthesis lesson: kabhi kabhi "ideal" timeout $T_{t a r g e t}$ reachable nahi hota aur design ka kaam yeh hota hai ki closest feasible configuration choose karo, phir verify karo ki margin comfortable hai — jo ki hai.

Problem 9 (L4)

Neeche diye buggy feed placement ko ek correct heartbeat mein refactor karo, aur ek sentence mein explain karo ki fix ab kaunsi class of bug catch karta hai.

void loop() {
    wdt_reset();                    // pehle feed kiya
    read_sensor();
    if (compute() < 0) {
        while (1) { /* error spin */ }   // intended "safe halt"
    }
    actuate();
}

Recall Solution

Corrected version — ek poori successful iteration ke baad feed karo:

void loop() {
    read_sensor();
    if (compute() < 0) {
        enter_safe_state();   // deliberate, phir WDT hume reset kare
        while (1) { }         // yahan koi feed nahi -> WDT recover karta hai
    }
    actuate();
    wdt_reset();              // heartbeat: sirf tab jab hum end tak pahunche
}

Yeh ab kya catch karta hai: koi bhi path jo poora loop body complete karne mein fail kare — deliberate error-spin sameta — kyunki feed tab hoti hai jab read_sensor → compute → actuate sab succeed kare. Buggy original mein, early feed ne error-spin ko recovery se pehle ek full fresh timeout diya, aur feed ke baad ek accidental infinite loop abhi bhi ek poore window ke liye mask hota. Safe State Design dekho ki hum reset hone se pehle outputs ko known-safe value par kyun drive karte hain, aur Fault Tolerance dekho recovery philosophy ke liye.

L5 — Mastery

Problem 10 (L5)

Ek window watchdog ek ISR-driven loop protect karta hai. Window hai $T_{min} = 60 ms < T_{f ee d} < T_{ma x} = 80 ms$ (jaise parent note mein; open interval ke andar strictly feeds legal hain). Ek timing bug ek interrupt har $10 ms$ fire karta hai, aur har firing loop run karke feed attempt karta hai.

(a) 8-firing span ( $t = 10, 20, \dots, 80 ms$ last successful refresh ke baad) mein, kitne attempted feeds legal window ke andar land karte hain? (b) Explain karo ki ek plain (non-window) watchdog is system ko perfectly healthy kyun report karta, aur window watchdog kya gain karta hai.

Recall Solution

(a) ISR last successful refresh ke baad $t = 10, 20, 30, 40, 50, 60, 70, 80 ms$ par fire karta hai. Feed tabhi legal hai jab $60 < t < 80$ (strictly inside).

$t = 10, 20, 30, 40, 50 ms$ : too early ( $t < 60$ ) → har ek strict window watchdog par reject / reset trigger karta hai.
$t = 60 ms$ : boundary par, aur $60 < 60$ false hai → too early, legal nahi.
$t = 70 ms$ : $60 < 70 < 80$ → legal ✅ — sirf yahi ek.
$t = 80 ms$ : boundary, $80 < 80$ false hai → too late.

Final count: exactly 1 legal feed ( $t = 70 ms$ par) 8 attempts mein se. Har doosra attempt ek window violation hai, toh window watchdog early feeds refuse karta hai aur tumhe $10 ms$ timing bug confront karne par majboor karta hai.

(b) Ek plain watchdog sirf poochta hai "kya tum $T_{ma x}$ se pehle feed kiye gaye?" Har $10 ms$ feeding easily satisfy karta hai — har $80 ms$ span mein 8 healthy-looking heartbeats — toh timing bug use bilkul invisible hai. Window watchdog lower bound $T_{min}$ add karta hai, question ko convert karta hai "kya tum SAHI rate par feed kiye gaye?" (na too fast, na too slow). Yahi woh cheez hai jo interrupt storms aur skipped-delay bugs catch karta hai jinhe plain watchdog sail past karta hai. Interrupt Service Routines cross-reference karo ki ISRs ko short aur rate-correct rakhna kyun matter karta hai, aur Real-Time Operating Systems dekho ki ek RTOS task-based watchdog ise per-task heartbeats tak kaise generalize karta hai.

Problem 11 (L5)

Multi-task heartbeat. Ek RTOS teen tasks run karta hai jo sabhi alive rehni chahiye. Ek common pattern: har task ek cycle complete hone par ek shared alive_flags word mein apna bit set karta hai; ek supervisor hardware watchdog tab feed karta hai jab sab bits set hon, phir unhe clear karta hai. Task A har $20 ms$ cycle karta hai, Task B har $50 ms$ , Task C har $100 ms$ . Minimum hardware-watchdog timeout kya hai jo healthy operation mein false-reset nahi karega, aur kyun?

Recall Solution

Supervisor sirf tab feed kar sakta hai jab teeno bits set hon, phir clear karta hai. Clear karne ke baad, agla feed tab tak nahi ho sakta jab tak har task ne kam se kam ek aur cycle complete na ki ho — aur sabse slow task, C, yeh gate karta hai, kyunki A aur B apne bits bahut pehle set kar dete hain aur C ke khatam hone se pehle already set ho jaate hain.

Do supervisor feeds ke beech worst-case gap $=$ Task C ki period $= 100 ms$ (plus thoda scheduling jitter).
Isliye hardware timeout satisfy karna chahiye $T_{t im eo u t} > 100 ms + jitter margin .$ $T_{t im eo u t} \approx 2 \times 100 = 200 ms$ choose karna slowest heartbeat par $100%$ margin deta hai jabki phir bhi genuine total hang $200 ms$ ke andar recover karta hai. Mastery point: multi-task system mein watchdog sirf tumhare slowest mandatory heartbeat jitni fast hoti hai — timeout us task se set karo, fast walon se nahi, warna ek stalled Task C healthy dikhega jab A aur B shared feed alive rakhenge. Flags par AND-gate wahi hai jo prevent karta hai ki ek fast task ek dead slow task ko mask kare.

Recall Quick self-audit checklist

Timeout formula: prescaler se multiply karo ::: $T_{t im eo u t} = \frac{N _{ma x}}{f _{c l oc k}} \times prescaler$ — bada prescaler matlab lamba timeout.
Prescaler solve karo ::: $prescaler = \frac{T _{t a r g e t} f _{c l oc k}}{N _{ma x}}$ , phir standard value par round karo.
Kahan feed karo ::: ek baar, ek complete iteration ke end par (heartbeat), kabhi pehle nahi, kabhi per-function nahi.
Window watchdog ::: sirf $T_{min} \leq T_{f ee d} \leq T_{ma x}$ mein legal; "reset when counter $\leq X$ " matlab last safe step $X + 1$ hai.
Multi-task ::: feed ko sab mandatory heartbeats ke AND par gate karo; timeout slowest task se set karo.