Watchdog timers — purpose, feeding, types: Question bank

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

Is page par sirf Watchdog timers — purpose, feeding, types ke ideas hain: watchdog ek hardware down-counter hai jo system ko reset karta hai jab tak software use waqt par "feed" (reload) na kare, aur yeh hardware-only, software-controlled, aur window flavours mein aata hai.

Is page ke symbols (traps se pehle defined)

Kisi bhi trap se pehle, neeche diya timeline dekho — yeh is page ke har question ke peeche ki mental picture hai.

Figure — Watchdog timers — purpose, feeding, types

Counter poora bhara shuru hota hai aur neeche tick karta hai. Jab yeh zero pe pahunchta hai, reset fire hoti hai. Picture teen moments clearly dikhati hai: safe feed window, zero tak countdown, aur woh race jo tab hoti hai jab tumhara feed exactly zero par land kare.

True ya false — justify karo

Watchdog timer ka kaam sirf infinite loops pakadna hai.

False. Yeh koi bhi aisi condition pakadta hai jo feed ko waqt par hone se rok de. Concrete cases: ek deadlock jahan do tasks ek doosre ka intezaar karte hain hamesha ke liye; memory corruption jo program counter ko garbage mein jump kara de jo kabhi feed tak nahi pahunchta; ek stalled clock; ek sensor read jo kisi mare hue hardware ka intezaar karte karte block ho jaye. Infinite loop toh sirf inme sabse famous hai.

Watchdog ko feed karna prove karta hai ki poora program sahi se kaam kar raha hai.

False. Feed sirf yeh prove karta hai ki feed instruction waqt par reach hua — kya value compute ki iske baare mein kuch nahi. Socho ek thermostat jiska control math buggy hai aur jo 200°C command karta hai, lekin jiska main loop schedule par chalta rehta hai aur khushi se feed karta rehta hai: watchdog chup rehta hai jabki output dangerously galat hai. Watchdog liveness check karta hai ("kya code abhi bhi move kar raha hai?"), kabhi correctness nahi ("kya code sahi answer ki taraf ja raha hai?").

Ek hardware-only watchdog, ek baar enable hone ke baad, software dwara band nahi kiya ja sakta.

True. Yahi "hardware-only" ka matlab hai: enable ek fuse ya write-once bit se lock hota hai, toh koi bhi wild pointer ya runaway ISR jo registers mein scribble karta ho, use clear nahi kar sakta. Compare karo ek software watchdog se, jahan ek bura register write silently tumhari poori safety net disable kar sakta hai.

Agar main CPU clock ruk jaye, toh watchdog tumhe ab nahi bacha sakta.

False (ek well-designed WDT ke liye). Ek robust watchdog ek alag clock source par chalta hai, usually ek internal RC oscillator. Toh jab main clock mar jaaye aur CPU freeze ho jaye, independent counter ticks karta rehta hai zero tak aur reset fire karta hai. Timeline figure mein, countdown line simply slide karti rehti hai chahe CPU frozen ho — woh independence hi alag clock ka poora reason hai.

Prescaler ko double karne se timeout period double ho jaata hai.

True — aur yeh hai iska vivid version. Maano

N_{ma x} = 65535

f_{c l oc k} = 128000

ticks/s. Prescaler = 64 ke saath:

T = \frac{65535}{128000} \times 64 \approx 32.8

s. Ab prescaler ko double karke 128 karo: har tick ko ab double clock pulses ka intezaar karna padta hai, toh har tick double lamba leti hai, aur

T = \frac{65535}{128000} \times 128 \approx 65.5

s. Formula mein aur kuch nahi badla, toh poora time exactly 2 se scale hua.

Ek window watchdog jise exactly window ke beech mein feed kiya gaye, woh ek normal watchdog jaisa behave karta hai.

Partially true, aur yahi trap hai. Mid-window feed dono types ke liye theek hai. Lekin window watchdog additionally reset karta hai agar tum kabhi

T_{min}

se pehle feed karo. Toh ek window watchdog kabhi bhi sirf stricter ho sakta hai, kabhi more lenient nahi — ek plain watchdog uss too-early feed ko khushi se accept kar leta jo ek window watchdog reject karta.

Ek software-controlled watchdog hardware-only se strictly zyada protection deta hai kyunki iske paas zyada configuration options hain.

False. Zyada options ≠ zyada protection. Kyunki software use disable kar sakta hai, corrupted ya buggy code silently use switch off kar sakta hai — exactly wahi failure jisse tum protect karna chahte the. Socho ek stack overflow jo config register ko zeros se overwrite kare: ek hardware-locked watchdog ko fark nahi padta; ek software wala ab dead hai. Flexibility ek kamzor guarantee ka daam cheeka hai.

Bahut lamba timeout choose karna "safe" choice hai kyunki iss se false resets avoid hote hain.

False. Lamba timeout false resets ko rare banata hai lekin real recovery slow karta hai — system restart hone se pehle poore timeout ke liye hung rehta hai. Agar woh watchdog ek motor controller guard karta hai, toh 30-second timeout ka matlab hai recovery se pehle 30 second ka frozen, possibly runaway motor. Timeout ek tradeoff hai false resets aur recovery latency ke beech, koi "bada matlab safe" dial nahi.

Error dhundho

wdt_reset() main loop ki bilkul pehli line ke roop mein rakha, kisi kaam se pehle.

Error: loop ke andar koi bhi hang kabhi detect nahi ho sakta. Counter pehle reload ho jaata hai potentially-hanging kaam se pehle, toh uss kaam ke andar ek hang ke baad bhi har iteration ke shuru mein ek poora fresh timeout milta hai. Tum feed karte ho, phir hang hote ho — ek poora waste timeout period khareedte ho. Critical kaam khatam hone ke baad feed karo, taaki feed proof ho ki kaam finish hua.

Ek window watchdog ko HAL_WWDG_Refresh() se ek loop ke har pass par feed kiya jaata hai jo

T_{min}

se kaafi faster chalti hai.

Error: har feed "bahut jaldi" hoti hai aur lower bound trip karta hai. Window watchdog

T_{min}

se pehle feeds par reset karta hai; ek bahut-fast loop jaldi feed karta hai, toh system reset hota hai chahe kuch hung na ho. Tum feed ko ek time check ke peeche gate karo taaki yeh sirf tab fire ho jab clock

(T_{min}, T_{ma x})

ke andar ho.

Watchdog ko 250 ms timeout ke saath enable karna, phir "kyunki 400 ms ka real kaam theek hai" kahte hue feeds ke beech delay(400) call karna.

Error: delay timeout se zyada hai, toh reset mid-delay fire hoti hai. Margin positive hona chahiye: feeds ke beech tumhara sabse lamba gap

T_{ma x}

se safely neeche hona chahiye, usse upar nahi. Yahan counter delay ke 150 ms mein zero tak pahunch jaata hai, toh system roughly har 250 ms par hamesha ke liye reset hota hai.

Ek "recovery" reset handler jo wahi initialization dobara chalaata hai jis ne hang cause kiya, bina kisi reason ke record ke.

Error: yeh ek reset loop bana sakta hai bina kisi diagnosis ke. Recovery ko reset-source register padhna chahiye (upar define kiya) yeh jaanne ke liye ki watchdog fire hua, fault log ya count karna chahiye, aur possibly crashing path ko blindly dobara try karne ki bajaye ek safe state mein enter karna chahiye. Dekho Fault Tolerance.

Ek lambe firmware-update routine ke andar watchdog disable karna, phir use re-enable karna bhool jaana.

Error: system ab hamesha ke liye unprotected chalta hai. Agar disable path liya gaya lekin re-enable skip ho gaya (ek early return, ek exception, ek jump), protection silently chali jaati hai bina kisi visible symptom ke. Hardware-locked watchdog prefer karo, ya ek design jahan update path watchdog ko disable karne ki bajaye feed kare. Yeh Bootloader Design se juda hai.

Watchdog ko ek timer interrupt ke andar se feed karna taaki "yeh hamesha schedule par fed ho."

Error: interrupt tab bhi chalta reh sakta hai jab main program dead ho. Agar ISR abhi bhi fire karta hai lekin main() deadlock ho gayi hai, toh ISR watchdog ko feed karta hai aur hang chhupaata hai. Feed us cheez par depend karni chahiye jo tum prove karna chahte ho alive hai — kisi independent timer par nahi jo regardless chale.

Why questions

Critical kaam ke baad watchdog feed kyun karo, loop ke top par nahi?

Kyunki feed ka matlab hai ki critical kaam actually complete hua — yeh saboot hona chahiye. Pehle feed karna ise ek rubber-stamp bana deta hai jo kuch prove nahi karta; baad mein feed karna ek missed feed ko genuinely matlab deta hai "hum is iteration mein finish nahi hue."

Ek window watchdog ko do bounds ki zaroorat kyun hai, sirf ek ki jagah?

Upper bound

T_{ma x}

hangs pakadta hai (feed kabhi nahi aati). Lower bound

T_{min}

runaway behaviour pakadta hai — ek tight loop ya interrupt storm jo bahut jaldi feed kare — jo ek one-sided watchdog healthy operation se distinguish nahi kar sakta. Saath mein yeh check karte hain "chal raha hai aur sahi rate par chal raha hai."

Hardware watchdog ko uska apna alag clock source kyun dete hain?

Taaki main clock ka failure — sabse catastrophic hang, jahan CPU completely frozen hai — abhi bhi recoverable ho. Us hi failing clock se clocked watchdog CPU ke saath freeze ho jaata aur kabhi fire nahi karta.

Watchdog reset dangerous kyun ho sakta hai agar tum pehle safe state design nahi karte?

Reset system ko mid-operation boot par wapas kheench leta hai. Agar outputs (motors, heaters, valves) reset par ek known-safe condition mein drive nahi kiye gaye, toh ek repeated watchdog reset loop actuators ko har cycle mein ek undefined, possibly hazardous state mein chod sakta hai.

Startup par reset-source register check karna important kyun hai?

Ek normal power-on reset aur ek watchdog-triggered reset naive boot code ko identical lagte hain, lekin bahut alag matlab rakhte hain. Source padhne se tum "fresh start" aur "hum abhi ek hang se recover hue hain" distinguish kar sakte ho, taaki tum fault log kar sako, count kar sako, ya safe state mein escalate kar sako. Dekho System Reset Sources.

Watchdog ko Fault Tolerance ka hissa kyun maana jaata hai, debugging ka nahi?

Debugging faults ko deploy hone se pehle dhundh kar hatata hai; watchdog un faults ko contain karta hai jo tum hatane mein fail hue, field system ko automatic recovery deta hai jab unexpected hota hai — yeh ek tolerance mechanism hai, diagnosis tool nahi.

Watchdog wrong but timely outputs wale bug se protect kyun nahi kar sakta?

Watchdog sirf yeh measure karta hai ki feed waqt par hua ya nahi. Ek program jo schedule par chale lekin garbage compute kare, perfectly on time feed karta hai, toh watchdog chup rehta hai. Correctness doosre tarike se pakadni chahiye — plausibility checks, redundancy, ya ek doosra monitoring channel.

Edge cases

Agar timeout period tumhari sabse lambi legitimate operation se chhoti ho toh kya hoga?

Tumhe false resets milenge: valid lambi operation

T_{ma x}

se aaage nikal jaati hai feed karne se pehle, aur system mid-task baar baar restart hota hai. Timeout tumhare worst-case feeds ke beech ke waqt se zyada hona chahiye, margin ke saath.

Agar ek corrupted program counter accidentally feed instruction mein jump kare baar baar?

Ek plain watchdog fooled ho jaata — use feeds milti hain aur yeh chup rehta hai. Yahan window watchdog help karta hai: random jumps rarely sahi rate par feeds produce karte hain, toh early ya late feeds tab bhi reset trip karte hain.

Exactly us instant kya hota hai jab counter zero reach karta hai jabki feed execute ho rahi hai?

Yeh ek genuine race hai — timeline figure par red "race at zero" marker dekho. Hardware ise deterministically resolve karta hai (usually reset jeet jaata hai, ya reload atomic hota hai), lekin tumhe kabhi bhi answer par rely nahi karna chahiye: hamesha

T_{ma x}

se neeche real margin rakho taaki race kabhi pehli jagah na ho.

Agar asynchronous interrupt jitter ya ISR latency tumhara feed delay kare?

Yeh subtle timing edge case hai. Tumhara loop sochta hai ki 70 ms par feed kare, lekin agar interrupts ka burst (ya ek lamba ISR) CPU time chura le, toh feed instruction postpone ho jaati hai. Do cheezein galat ho sakti hain: ek plain watchdog ke saath delayed feed

T_{ma x}

se slip karke false reset cause kar sakti hai; ek window watchdog ke saath, jitter feed ko

(T_{min}, T_{ma x})

ke kisi bhi side se bahar push kar sakta hai. Fix yeh hai ki window ko nominal timing ke nahi, worst-case interrupt latency ke against size karo. Related: Interrupt Service Routines aur Real-Time Operating Systems.

Agar watchdog register mein write khud fail ho jaye — ek bus error ya ek ECC-corrected fault store ko stall kare?

Toh ek "valid" feed silently kabhi land nahi karta: code chala, refresh call kiya, lekin counter actually reload nahi hua, toh watchdog timeout ho jaata hai aur reset karta hai chahe software alive tha. Yeh ek real failure mode hai complex SoCs par. Defences: reload confirm karne ke liye counter read back karo, ya ek unexpected watchdog reset ko (reset-source register ke zariye) signal maano ki register path khud faulty ho sakta hai. Fault Tolerance aur Hardware Timer Peripherals se juda hai.

Agar tum timeout maximum possible value par set karo, effectively "off"?

Watchdog technically abhi bhi chalta hai lekin itna slow hai ki yeh almost koi timely protection nahi deta — ek hung system minutes ke liye frozen rehta hai. Functionally yeh ek enabled watchdog ke kapdon mein disabled watchdog hai, purpose ko defeat karta hai.

Ek system ke saath watchdog kaise interact karta hai jo legitimately lambe periods sleep / low-power mode mein spend karta hai?

Tumhe ya toh ek watchdog use karna chahiye jo uss sleep mode mein counting karta rehta hai (aur ek wake source se feed karo) ya jo deep sleep mein pause kare. Ek mismatch ya toh valid sleep ke dauran false reset cause karta hai ya sleep ke dauran lost protection. Related: Real-Time Operating Systems aur Hardware Timer Peripherals.

Agar watchdog ka apna oscillator temperature ke saath drift kare?

Real timeout bhi drift karta hai, toh ek "500 ms" watchdog 400 ms ya 650 ms par fire kar sakta hai across temperature. Apna feed margin worst-case timeout ke against size karo, nominal ke nahi.

Kya ek watchdog reset ek brown-out event ke saath coincide kar sakta hai, aur kya yeh matter karta hai?

Haan — ek sagging supply dono software corrupt kar sakta hai (watchdog trigger karte hue) aur brown-out detection trip kar sakta hai. Reset-source register flags tumhe yeh batane mein help karte hain ki pehle kaun fire hua, taaki recovery code ek power fault ko software hang se galat na maane.

Recall Self-test: kaun sa watchdog kaun se fault ke liye?

Fault ko sabse strong defence se match karo. Program counter corrupt ho gaya toh software WDT disable karta hai ::: Hardware-only (locked) watchdog — software use switch off nahi kar sakta. Interrupt storm bahut jaldi feed kar raha hai ::: Window watchdog — lower bound $T_{min}$ early feeds pakadta hai. Main clock mar gayi, CPU frozen hai ::: Koi bhi watchdog alag clock source par — yeh counting karta rehta hai. Firmware update ke dauran protection disable karne ki zaroorat hai ::: Software-controlled watchdog — lekin re-enable ko carefully design karo.