Worked examples — Watchdog timers — purpose, feeding, types

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

Yeh page parent watchdog note ki "no case left behind" companion hai. Shuru karne se pehle, woh ek formula dobara samajhte hain jis par neeche sab kuch tika hua hai, taaki koi bhi symbol bina explanation ke na aaye.

Figure 1 ise ek picture mein dikhata hai: blue line ko $N_{max}$ se neeche ramp karte dekhein, aur har yellow dot ko ise top par snap karte dekhein — woh snap ek "feed" hai. Zero par red dashed line woh jagah hai jahan reset fire hoti hai.

---

Scenario matrix

Watchdog topic se aane wala har sawaal in cells mein se kisi ek mein rehta hai. Baad ke examples har baar announce karte hain ki woh kaun si cell fill kar rahe hain.

Cell	Case class	Kya test ho raha hai
A	Plain timeout, saari values di hui hain	Formula ka direct use
B	Prescaler ke liye backwards solve karna	Target $T$ paane ke liye $P$ chunna
C	8-bit vs 16-bit counter (chhota $N_{max}$)	Counter width ka effect
D	Zero / degenerate input ($P=1$, ya "kabhi feed nahi")	Limiting behaviour, sanity edges
E	Feed-margin: kya loop time par khatam hoti hai?	Worst-case loop timing
F	Too-late fault (ek hang)	Regular WDT slow/frozen code ko pakadta hai
G	Too-early fault (window WDT)	Window WDT fast/runaway code ko pakadta hai
H	Real-world word problem	Ek real device ke liye timeout chunna
I	Exam twist (interrupt storm "healthy" lagta hai)	Window kyun zaroori hai

---

Worked examples

Example 1 — Cell A: plain timeout

Forecast: pehle andaza lagao — kya yeh milliseconds, seconds, ya minutes mein hoga? Likh lo.

1. $f_{clock}$ ko Hz mein likho. $128\text{kHz}=128000\text{Hz}$. Yeh step kyun? Formula ko pulses-per-second chahiye, aur "k" ek $1000$ ka factor chhupata hai; units saaf rakhne se 1000× errors bachte hain.
2. Plug in karo. $T=\frac{65535}{128000}\times 64$ (yaad rahe $T\equiv T_{timeout}$). Yeh step kyun? Direct application — har symbol known hai.
3. Arithmetic. $\frac{65535}{128000}=0.51199$ s per full count at $P=1$; times $64$ deta hai $32.77$ s. Yeh step kyun? Ise split karna middle number ($0.512$ s) dikhata hai jo "no-prescaler" timeout hai, jise hum baad mein reuse karte hain.

$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, parent note ke $P=64$ wale number se match karta hai.

---

Example 2 — Cell B: prescaler ke liye backwards solve karna

Forecast: andaza lagao ki aapko chhota $P$ chahiye ya bada.

1. Formula ko $P$ ke liye rearrange karo. $T=\frac{N_{max}}{f_{clock}}P$ se, $P=\frac{T{f}_{clock}}{N_{max}}$ isolate karo. Yeh step kyun? Hume jawab $T$ pata hai aur knob $P$ chahiye — isliye $P$ ko akela rakho.
2. Target plug in karo. $P=\frac{0.5\times 128000}{65535}=\frac{64000}{65535}=0.976$. Yeh step kyun? Yeh ideal $P$ woh hai jo aapko chahiye hoga agar prescalers continuous hote.
3. Fixed menu par snap karo. $0.976$ sabse kareeb $1$ ke hai. Yeh step kyun? Hardware sirf upar define kiya gaya discrete menu offer karta hai; aapko ek ऐसी value par round karna hai jo physically exist karti ho.
4. $P=1$ par real timeout check karo. $T=\frac{65535}{128000}\times 1=0.512\text{s}=512\text{ms}$. Yeh step kyun? Delivered timeout, ideal wala nahi, woh hai jo actually aapki protection karta hai.

Verify: $512\text{ms}$, $500\text{ms}$ target se $2.4\%$ ke andar hai — kisi bhi menu prescaler se itna hi kareeb ja sakte hain. ✓

---

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

Forecast: kya 8-bit version chhota hoga ya lamba, aur roughly kitne factor se?

1. 8-bit timeout. $T_8=\frac{255}{1000000}\times 256=0.06528\text{s}=65.28\text{ms}$. Yeh step kyun? Chhote $N_{max}$ ke saath direct formula.
2. 16-bit timeout, same knobs. $T_{16}=\frac{65535}{1000000}\times 256=16.777\text{s}$. Yeh step kyun? Sirf woh cheez isolate karo jo badi — counter width.
3. Ratio. $\frac{T_{16}}{T_8}=\frac{65535}{255}=257.0$. Yeh step kyun? Dikhata hai ki counter width timeout ko linearly scale karti hai — wider counter hundreds of times zyada patience deta hai.

Verify: $65535/255=257$ exactly (kyunki $65535=255\times 257$). ✓ Narrow counter aapko ya toh bahut baar feed karne par majboor karta hai ya huge prescaler use karne par.

---

Example 4 — Cell D: degenerate inputs & limits

Forecast: sabse chhote timeout ka andaza lagao aur socho kya hoga agar aap kabhi feed na karo.

1. $P=1$ no-divide limit hai. $T=\frac{65535}{128000}\times 1=0.512\text{s}$. Yeh step kyun? $P=1$ har clock pulse pass karta hai — koi slowing nahi — isliye yeh is hardware ke timeout range ka floor hai.
2. "Kabhi feed nahi" interpret karo. Counter simply $65535\to 0$ ek baar run karta hai, bina ruke, phir ek reset trigger karta hai. Yeh step kyun? Ek watchdog jo enable hai lekin kabhi feed nahi hota woh exactly ek timeout ke baad guarantee se fire karta hai — yeh dead-man's-switch limit hai.
3. Degenerate case $P=0$? Illegal — menu par aisa koi prescaler exist nahi karta; clock ko $0$ se divide karna meaningless hai. Yeh step kyun? Invalid input cover karo taaki reader kabhi iska expect na kare. Hardware simply $P=0$ offer nahi karega.

Verify: Sabse chhota timeout $512\text{ms}$ Example 1 ke split ke $P=1$ row ke barabar hai. ✓ Examples ke beech consistency formula confirm karti hai.

---

Example 5 — Cell E: feed-margin timing

Forecast: margin ms mein guess karo, phir doubling ke liye yes/no guess karo.

1. Feeds ke beech worst-case time = full loop. $t_{loop}=50+100+50=200\text{ms}$. Yeh step kyun? Kyunki hum sirf loop ke baad feed karte hain (parent ke [!mistake] ko dekho jo bahut jaldi feed karne par hai), do feeds ke beech gap ek poori loop hai.
2. Margin. $M=T_{timeout}-t_{loop}=500-200=300\text{ms}$. Yeh step kyun? Margin woh slack hai jisse pehle ek legitimate slow loop dog ko trip karti hai. Positive margin = safe.
3. Doubling sawaal directly answer karo. $100\text{ms}$ task double karo → naya loop $=50+200+50=300\text{ms}$. Timeout se compare karo: $300<500$, isliye haan, yeh phir bhi safe hai, naye margin ke saath $500-300=200\text{ms}$. Yeh step kyun? Sawaal ne ek specific 2× scenario poocha, isliye hum woh exact case compute karte hain na ki ek general bound.
4. Woh task kitna bada ho sakta hai trouble se pehle? Fixed tasks $50+50=100\text{ms}$ kha jaate hain, beech wale task ke liye $500-100=400\text{ms}$ bachte hain — isliye woh $100\text{ms}$ se badhkar $400\text{ms}$ tak ja sakta hai (4× blow-up) timeout edge ko touch karne se pehle. Yeh step kyun? 2× answer ko poore safe range ke andar frame karta hai, taaki reader specific case aur uska headroom dono dekhe.

Figure 2 ise ek bar ke roop mein dikhata hai: blue chunk loop hai, green chunk margin hai, aur red dashed line woh timeout hai jise dono milkar cross nahi karne chahiye.

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: ek "too-late" fault (ek hang)

$t_0$ = last successful feed ka time (woh aakhri moment jab counter $N_{max}$ par reload hua). Neeche saari timing $t_0$ se measure ki gayi hai.

Forecast: andaza lagao ki hang shuru hone ke kitne ms baad reset hota hai.

1. Last good feed. Iteration 6 ne $t_0$ par finish karke feed kiya. Counter $N_{max}$ par reload hota hai. Yeh step kyun? Reset clock last successful feed $t_0$ se shuru hota hai, hang se nahi.
2. Counter free-runs. Aur koi feeds nahi, counter $N_{max}\to 0$ march karta hai, poora $T_{timeout}=500\text{ms}$ leta hai. Yeh step kyun? Hang = feeding ruk gayi = Example 4 ka never-fed limit kick in karta hai.
3. Reset instant. Reset $t_0+500\text{ms}$ par fire hoti hai. Dead time (hang start se, jo $t_0$ ke $\le 200\text{ms}$ baad hai) at most $500\text{ms}$ hai. Yeh step kyun? Downtime ka guaranteed upper bound deta hai — woh number jo ek safety engineer ko care karta hai.

Figure 3: green vertical lines $t_0$ tak healthy feeds hain; red band bina feeds ka hang hai; red dashed line $t_0+500\text{ms}$ par reset mark karti hai.

Verify: Dead time $\le T_{timeout}=500\text{ms}$ ✓. Agar hang feed ke right baad shuru ho, worst-case downtime = $500\text{ms}$; agar loop mein der se ho, kam. Dog hamesha ek timeout ke andar recover karta hai.

---

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

Ek window watchdog feed sirf ek time window ke andar accept karta hai. Define karo, previous feed ke baad se measure karke:

• $T_{min}$ — sabse jaldi legal feed time. $T_{min}$ se pehle feed karna ek fault hai (code bahut tez chal raha hai).
• $T_{max}$ — sabse der legal feed time. $T_{max}$ ke baad feed karna ek fault hai (code hung, plain dog ki tarah).
• $T_{feed}$ — actual time, last feed ke baad se, jis par yeh feed hoti hai.

Rule hai $T_{min}<T_{feed}<T_{max}$. Is example mein hardware set hai taaki $T_{min}=60\text{ms}$ aur $T_{max}=80\text{ms}$.

Forecast: legal ya reset? Aur kaun sa bound violate hota hai?

1. Lower bound se compare karo. $T_{feed}=40\text{ms}$, aur $T_{min}=60\text{ms}$. Kyunki $40<60$, hum bahut jaldi feed kar rahe hain. Yeh step kyun? Ek window watchdog ke paas do comparators hote hain; early feed "not before $T_{min}$" test fail karta hai.
2. Result. $T_{min}$ se pehle feed karna ek fault treat hota hai → reset. Yeh step kyun? Lower bound ka poora point yahi hai: code jo bahut tez chal raha hai (ek interrupt storm, ek runaway loop) utna hi broken hai jitna frozen code.
3. Plain watchdog kyun miss karta hai. Ek plain dog sirf $T_{feed}<T_{max}$ check karta hai. Kyunki $40<80$, woh fast feed happily accept kar leta aur "healthy" dekhta. Koi upper-only dog early detect nahi kar sakta. Yeh step kyun? Exactly woh gap name karta hai jo window fill karta hai — ek regular WDT ka koi lower bound hi nahi hota.

Figure 4 timeline ko last feed ke baad teen zones mein shade karta hai: ek red "too early" zone $T_{min}$ se neeche, ek green "OK window" dono bounds ke beech, aur ek red "too late" zone $T_{max}$ ke upar. $40\text{ms}$ par yellow dot red early zone mein padta hai.

Verify: $40<60=T_{min}$ → window ke bahar → reset ✓. Plain dog sirf $T_{max}=80$ ke saath: $40<80$ → accepted, bug hidden ✓ (proving window zaroori hai).

---

Example 8 — Cell G/D limit: bilkul boundary par

Forecast: kya endpoints andar hain ya bahar?

1. Strict inequalities interpret karo. Bounds strict hain ($<$, na ki $\le$): open interval $(60,80)$. Yeh step kyun? Boundary behaviour ek classic degenerate case hai — "exactly edge par" ko pin down karna zaroori hai.
2. Har ek test karo. $60$: fail karta hai ($60\ngtr 60$). $70$: safe ($60<70<80$). $80$: fail karta hai ($80\nless 80$). Yeh step kyun? Edges par dono comparators literally apply karta hai.
3. Design lesson. Centre ($70\text{ms}$) aim karo, kabhi edge nahi, taaki kuch ms ka clock jitter aapko bahar na dhakele. Yeh step kyun? Real clocks drift karte hain; dono sides par margin safe target hai.

Verify: Sirf $70\text{ms}$ satisfy karta hai $60<T_{feed}<80$ ✓; dono endpoints strict inequalities se exclude hain ✓.

---

Example 9 — Cell H: real-world word problem

Forecast: andaza lagao kaunsa menu prescaler jeetega.

1. Requirement set karo. $T>4\text{s}$ chahiye (ek cycle) $2.5\text{s}$ transmit ke liye slack ke saath — roughly $6\text{–}20\text{s}$ target: itna lamba ki false-trip kabhi na ho, itna chhota ki jaldi recover ho. Yeh step kyun? Timeout feeds ke beech sabse lamba legitimate time exceed karna chahiye, warna valid long operations false resets trip kar deti hain.
2. Base ($P=1$) timeout ek baar compute karo. $T_1=\frac{65535}{32768}=2.0\text{s}$. Yeh step kyun? Har menu value sirf is base ko $P$ se scale karti hai, isliye ise ek baar compute karne se baaki sab multiply karke mil jaate hain.
3. $T_1$ ko $P$ se multiply karke menu scan karo.
   • $P=1$: $2.0\text{s}$ — $2.5\text{s}$ transmit se chhota → false resets. Reject.
   • $P=8$: $2.0\times 8=16.0\text{s}$ — $4\text{s}$ se comfortably upar aur $2.5\text{s}$ se bhi upar; sane time mein recover karta hai. Accept.
   • $P=64$: $2.0\times 64=128\text{s}$ — hang se recover karne mein do minute se zyada; needlessly slow. Reject. Yeh step kyun? Menu walk karna dikhata hai ki $P=8$ sabse chhota prescaler hai jo dono legitimate operations clear karta hai, sabse tezi se safe recovery deta hai.
4. Chuna hua timeout state karo. $P=8$ ke saath: $T=\frac{65535}{32768}\times 8=16.0\text{s}$. Yeh step kyun? Final deliverable — woh number jo aap actually device mein program karte ho.

Verify: $P=8$ deta hai $16.0\text{s}>4\text{s}$ ✓ aur $>2.5\text{s}$ transmit ✓; $P=1$ deta hai $2.0\text{s}<2.5\text{s}$ → correctly rejected ✓; $P=64$ deta hai $128\text{s}$, over-long ✓. Aisi reset ke baad device ko kya karna chahiye iske liye Fault Tolerance aur Safe State Design dekhein.

---

Example 10 — Cell I: exam twist (interrupt storm "healthy" lagta hai)

Forecast: $80\text{ms}$ mein feed count guess karo.

1. Feeds count karo. Har $10\text{ms}$ mein ek feed, isliye $80\text{ms}$ mein: $80/10=8$ feeds. Yeh step kyun? Feeding ki frequency batati hai ki dog system health kaise "dekhta" hai.
2. Plain dog ko yeh healthy kyun lagta hai. Har feed $T_{max}=80\text{ms}$ se bahut pehle hoti hai, isliye counter kabhi zero nahi pahunchta. Plain dog "alive" report karta hai — even though timing $7\times$ bahut tez hai. Yeh step kyun? Blind spot expose karta hai: ek plain dog jawab deta hai "kya yeh chal raha hai?" na ki "kya yeh sahi rate par chal raha hai?"
3. Window dog reaction. Window $60<T_{feed}<80$ ke saath (so $T_{min}=60\text{ms}$), $T_{feed}=10\text{ms}$ par ek feed lower bound violate karti hai ($10<60$) → pehli hi fast feed par reset, aapko timing bug dhundhne par majboor karta hai. Yeh step kyun? Directly dono watchdog types ko us exact failure par contrast karta hai jo regular dog nahi dekh sakta. Yeh "window kyun exist karte hain" ki punchline hai.
4. Resolution. System storm par reboot karta hai, apni safe state mein enter karta hai, aur developer ek reset dekhta hai jo too-early feed se traceable hai — timing bug ab visible aur fixable hai na ki silently behaviour corrupt kar raha hai. Yeh precisely woh case hai jise ek plain watchdog mask kar deta; Real-Time Operating Systems bhi dekhein jahan per-task feed timing schedule hoti hai. Yeh step kyun? Scenario close karta hai: sirf "reset hoti hai" nahi balki "bug diagnosable ban jaata hai", jo Cell I ka poora payoff hai.

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

$N_{max}=65535$, $f=128\text{kHz}$, $P=64$ ke liye timeout? ::: $32.77\text{s}$ $128\text{kHz}$, 16-bit par $500\text{ms}$ ke kareeb paane ke liye sabse chhota menu prescaler? ::: $P=1$, deta hai $512\text{ms}$ Equal clock aur prescaler par 16-bit se 8-bit timeout ka ratio? ::: exactly $257$ $500\text{ms}$ dog ke saath hang ke liye worst-case downtime? ::: $\le 500\text{ms}$ (ek full timeout) Agar $100\text{ms}$ middle task double hokar $200\text{ms}$ ban jaaye $500\text{ms}$ dog ke under, safe hai? ::: haan — loop $300\text{ms}<500\text{ms}$ ban jaata hai Kaun sa watchdog woh feed pakadta hai jo bahut jaldi aati hai? ::: window watchdog (lower bound $T_{min}$) $80\text{ms}$ mein feeds agar ek ISR har $10\text{ms}$ mein feed kare? ::: $8$ — aur plain dog ise "healthy" dekhta hai