Watchdog timers — purpose, feeding, types

5.5.23 · Coding › Embedded Systems & Real-Time Software

Overview

Ek watchdog timer (WDT) ek hardware timer hai jo automatically system ko reset ya interrupt karta hai agar software periodically usse "feed" karna fail kar de. Yeh ek fault-tolerance mechanism hai jo embedded systems ko software hangs, infinite loops, aur deadlocks se protect karta hai.

Embedded systems mein, software "hang" ho sakta hai bugs, memory corruption, ya hardware faults ki wajah se. Bina kisi intervention ke, system indefinitely frozen rehta hai. Ek watchdog timer system ko force karta hai ki ya toh woh prove kare ki woh alive hai (timer reset karke), ya automatically restart ho jaaye.

YEH KYUN MATTER KARTA HAI: Embedded systems aksar unattended critical applications mein run karte hain (medical devices, automotive, industrial control). Ek software hang catastrophic ho sakta hai. Watchdog automatic recovery provide karta hai bina human intervention ke.

The Fundamental Mechanism

YEH KAISE KAAM KARTA HAI:

1. Initialization: WDT ko timeout period ke saath configure karo (e.g., 500ms)
2. Enable: Countdown shuru karo
3. Normal operation: Software timeout period ke andar timer ko "feed" (reset) karta hai
4. Fault condition: Agar software hang ho jaaye, feeding ruk jaati hai → timer expire hota hai → system reset/interrupt
5. Recovery: System restart hota hai, ideally fault se recover karta hai

$T_{timeout}=\frac{N_{max}}{f_{clock}}\times \text{prescaler}$

Jahan:

• $T_{timeout}$ = timeout period (seconds)
• $N_{max}$ = maximum counter value (hardware-dependent, aksar 16-bit = 65535)
• $f_{clock}$ = clock frequency jo WDT ko feed karti hai
• prescaler = clock divider (1, 8, 64, 256, 1024 typical values)

YEH FORMULA KYUN HAI? Watchdog sirf ek down-counter hai jo divided system clock se clock hota hai. Timeout woh time hai jitna lagta hai $N_{max}$ se 0 tak count karne mein divided clock rate par.

DERIVATION:

• Counter har clock cycle mein ek baar decrement hota hai divided frequency par
• Divided frequency: $f_{divided}=\frac{f_{clock}}{\text{prescaler}}$
• Time per decrement: $\Delta t=\frac{\text{prescaler}}{f_{clock}}$
• $N_{max}$ decrements ke liye total time: $T_{timeout}=N_{max}\times \Delta t=\frac{N_{max}\times \text{prescaler}}{f_{clock}}$

Timeout calculate karo: $T_{timeout}=\frac{65535}{128000}\times 1024=\frac{67,107,840}{128000}=524.28\text{ seconds}\approx 8.7\text{ minutes}$

Ruko, yeh toh bahut zyada lamba hai! Zyaatar embedded systems chhote prescalers use karte hain. Prescaler = 64 ke saath: $T_{timeout}=\frac{65535}{128000}\times 64=32.77\text{ seconds}$

YEH KYUN MATTER KARTA HAI? Tum prescaler choose karte ho is basis par ki kitni jaldi recovery chahiye. Longer timeout = valid lambi operations ke liye zyada tolerance. Shorter timeout = hangs se faster recovery lekin valid lambi operations ke dauran false resets ka risk.

Types of Watchdog Timers

1. Hardware-Only Watchdog

Characteristics:

• CPU core se independent
• Aksar alag clock source use karta hai (internal RC oscillator)
• Dedicated register write ya I/O pin toggle se reset hota hai
• Configuration startup ya fuses ke zariye lock hoti hai

Feeding mechanism:

// AVR example - write specific value to WDT register
WDTCSR |= (1 << WDE);  // Enable watchdog
// In main loop:
wdt_reset();  // Clears the timer (inline assembly: __asm__ __volatile__ ("wdr"))

ALAG CLOCK KYUN? Agar main clock fail ho jaaye, system hang ho jaata hai lekin watchdog apne independent clock par chalta rehta hai aur reset trigger kar sakta hai.

void setup() { // Configure for 250ms timeout wdt_enable(WDTO_250MS); // Macro sets prescaler bits }

void loop() { // Do work... critical_sensor_read(); compute_control_output(); // Feed watchdog before timeout wdt_reset(); // Must happen within250ms delay(100); // Safe - leaves150ms margin }

**YEH STEP KYUN?** `wdt_enable()` hardware bits set karta hai jo timeout configure karte hain. `wdt_reset()` counter ko maximum par reset karta hai. Agar `loop()` kisi bhi function mein hang ho jaaye, toh reset kabhi nahi hota, timer expire hota hai, system reset ho jaata hai.

> [!mistake] Bahut Zyada Frequently Feeding Karna
> **Galat approach:**
> ```c
> void loop() {
>     wdt_reset();  // First thing in loop
>     potentially_hanging_function();  // Bug here never detected!
> }
> ```

**YEH SAHI KYUN LAGTA HAI:** "Main watchdog ko immediately reset kar dunga taaki main kabhi bhoolunga nahi."

**Problem:** Agar `potentially_hanging_function()` hang ho jaaye, toh watchdog already reset ho chuka tha, toh recovery se pehle tumhe poora timeout period milta hai. Aur bura, agar ek tight loop ho jo zyaatar code ko bypass karta hai lekin reset ko hit karta hai, toh watchdog kabhi logic error nahi pakadta.

**Fix:** Watchdog ko critical operations successfully complete hone ke ==baad== feed karo, isse ek "heartbeat" ki tarah use karo jo prove karta hai ki main loop poori tarah execute hua:
```c
void loop() {
    sensor_read();
    process_data();
    update_outputs();
    
    wdt_reset();  // Only feed if we completed full loop iteration
}

2. Software-Controlled Watchdog

Characteristics:

• Register writes se band kiya ja sakta hai
• Zyada configuration options (interrupt vs reset)
• Wild pointers ya stack corruption ke against kam protection

Feeding mechanism:

// STM32 example
HAL_IWDG_Refresh(&hiwdg);  // Reload counter register

SOFTWARE CONTROL KYUN ALLOW KARTE HAIN? Debugging, development, ya firmware updates ke dauran, tumhe watchdog disable karna pad sakta hai. Production systems aksar hardware-locked watchdogs use karte hain.

3. Window Watchdog

Jahan:

• $T_{min}$ = minimum time jiske baad feeding allowed hai
• $T_{max}$ = maximum time jiske baad feeding timeout cause karti hai
• $T_{feed}$ = actual time jab feed hota hai

DO BOUNDS KYUN?

• Upper bound ($T_{max}$): Normal watchdog ki tarah, hangs pakadta hai
• Lower bound ($T_{min}$): Code ko bahut tezi se run hone par pakadta hai (interrupt storms, tight loops, timing bugs)

Bounds ka DERIVATION: Hardware mein, ek window watchdog do comparators use karta hai:

• Counter value upper threshold se compare hoti hai: $Counte{r}_{current}<Threshol{d}_{upper}$ → reset
• Counter value lower threshold se compare hoti hai: $Counte{r}_{current}>Threshol{d}_{lower}$ → reset allowed

Time mapping: $Counte{r}_{current}=N_{max}-\frac{t\times f_{clock}}{prescaler}$

Is tarah:

• $T_{min}=\frac{N_{max}-Threshol{d}_{lower}}{f_{clock}}\times prescaler$
• $T_{max}=\frac{N_{max}-Threshol{d}_{upper}}{f_{clock}}\times prescaler$

uint32_t last_feed = 0;

void loop() { uint32_t now = HAL_GetTick(); // milliseconds

do_critical_work();

// Feed only in valid window
if (now - last_feed >= 60 && now - last_feed <= 80) {
    HAL_WWDG_Refresh(&hwdg);
    last_feed = now;
}

}

**Scenario - bug pakda gaya:** Maano ek interrupt har 10ms mein fire hota hai aur `loop()` call karta hai. Window watchdog ke bina, normal watchdog ko 80ms period mein 8 baar feed hota hai - healthy lagta hai! Lekin timing galat hai. Window watchdog system ko reset karta hai kyunki 10ms par feeding bahut jaldi hai, tumhe timing bug fix karne ke liye majboor karta hai.

**YEH STEP KYUN?** Window watchdogs sirf "kya code chal raha hai?" enforce nahi karte balki "kya code SAHI RATE par chal raha hai?" bhi enforce karte hain. Yeh timing violations pakadta hai jo regular watchdogs miss kar dete hain.

## Watchdog Feeding Strategies

### Strategy 1: Main Loop Heartbeat

```c
void main() {
    wdt_enable(WDTO_500MS);
    
    while(1) {
        task();  // 50ms
        task2();  // 100ms
        task3();  // 50ms
        // Total: ~200ms per iteration
        wdt_reset();  // Heartbeat - proves full loop executed
    }
}

YEH KYUN KAAM KARTA HAI? Har feed prove karta hai ki saari tasks complete hui. Agar koi task hang ho jaaye, feed nahi hota, timeout trigger hota hai.

Timeout sizing: $T_{timeout}$ > worst-case loop time + margin. Yahan: 500ms > 200ms + margin.

Strategy 2: Task-Based Feeding (RTOS)

// FreeRTOS example
void watchdog_task(void *param) {
    const TickType_t feed_interval = pdMS_TO_TICKS(200);
    
    while(1) {
        // Check if all critical tasks reported in
        if (task1_alive && task2_alive && task3_alive) {
            wdt_reset();
            task1_alive = false;  // Reset flags
            task2_alive = false;
            task3_alive = false;
        }
        vTaskDelay(feed_interval);
    }
}
 
void critical_task1(void *param) {
    while(1) {
        do_work();
        task1_alive = true;  // Report health
        vTaskDelay(pdMS_TO_TICKS(50));
    }
}

YEH APPROACH KYUN? Multiple tasks wale RTOS mein, watchdog task sirf tab feed karta hai jab SAARI critical tasks ne report kiya ho. Agar koi task hang ho jaaye, system reset ho jaata hai.

Feed interval ka DERIVATION:

• Har critical task har $T_{task}$ par report karti hai
• Watchdog task har $T_{check}$ par check karta hai
• Timeout satisfy karna chahiye: $T_{timeout}>\max (T_{task})+T_{check}+margin$

Agar task har 50ms par report kare, watchdog har 200ms par check kare, toh timeout > 250ms + margin = 500ms hona chahiye.

Problem: Watchdog ko kitni baar feed karein?

Analysis:

• Sabse lamba critical period: Task C 1000ms par
• Watchdog timeout > 1000ms hona chahiye Task C ko complete hone dene ke liye
• Timeout = 1500ms set karo (sabse lambe period ka 1.5×, margin ke liye)
• Watchdog task 500ms par run karta hai, saari tasks se "alive" flags collect karta hai
• Sirf tab feed karo jab saare flags set hon

YEH NUMBERS KYUN? Har task successful completion ke baad apna flag set karta hai. Watchdog task verify karta hai ki saari tasks pichle check period (500ms) mein run hui. Lekin timeout 1500ms hai Task C ke 1000ms period ko tolerate karne ke liye. Agar koi task >1500ms ke liye fail kare, system reset ho jaata hai.

YEH SAHI KYUN LAGTA HAI: "Agar koi bhi task alive hai, watchdog feed karo."

Problem: System partially failed ho sakta hai. Task1 aur Task2 hang ho jaate hain, lekin Task3 chalta rehta hai aur watchdog feed karta rehta hai. Critical functions broken hain lekin system reset nahi hota.

Fix: AND logic use karo - SAARI critical tasks ko report karna chahiye:

if (task1_alive && task2_alive && task3_alive) {  // AND - correct
    wdt_reset();
}

Strategy 3: Hierarchical Feeding

Complex systems ke liye, multiple watchdogs use karo:

1. Hardware watchdog (1s timeout): Last resort, total system hang pakadta hai
2. Software watchdog (500ms): Main loop monitor karta hai, hard reset se pehle interrupt generate kar sakta hai
3. Task watchdogs (per-task timeouts): Har critical task ka apna monitor hota hai

LAYERS KYUN? Defense in depth. Inner layers problems ko jaldi pakadti hain zyada context ke saath (interrupt handler hard reset se pehle state log kar sakta hai). Outer layer recovery guarantee karta hai chahe inner layers fail ho jaayein.

Watchdog Timer Reset Handling

Jab watchdog trigger hota hai, system reset hota hai. Firmware ko startup par yeh detect karna chahiye:

#include <avr/wdt.h>
 
void setup() {
    uint8_t reset_source = MCUSR;  // Read reset status register
    MCUSR = 0;  // Clear for next time
    
    if (reset_source & (1 << WDRF)) {
        // Watchdog caused reset
        log_error("WDT reset occurred");
        error_count++;
        
        if (error_count > 3) {
            enter_safe_mode();  // Too many resets, something seriously wrong
        }
    }
    wdt_enable(WDTO_500MS);  // Re-enable watchdog
}

RESET SOURCE KYUN CHECK KAREIN? Watchdog resets ko power-on, brown-out, ya software resets se alag pehchanein. Samay ke saath watchdog resets track karo chronic reliability issues detect karne ke liye.

$T_{recovery}=T_{reset}+T_{boot}+T_{init}$

Jahan:

• $T_{reset}$ = hardware reset pulse duration (typically 1-10ms)
• $T_{boot}$ = bootloader execution time (0ms agar koi bootloader nahi, ya 50-500ms)
• $T_{init}$ = application initialization time (variable, minimize karna chahiye)

YEH KYUN MATTER KARTA HAI? Real-time systems mein, watchdog recovery $T_{recovery}$ duration ka service interruption cause karta hai. Initialization ko jitna ho sake fast design karo aur safe startup ensure karo.

DERIVATION: Yeh times serially add hote hain kyunki har ek dusre ke complete hone se pehle start nahi ho sakta. Har component minimize karo:

• $T_{reset}$: Hardware fixed, typically < 10ms
• $T_{boot}$: Production mein bootloader disable karo ya fast bootloader use karo
• $T_{init}$: Pehla watchdog feed karne se pehle sirf critical subsystems initialize karo; non-critical init defer karo

Target: Zyaatar embedded systems ke liye $T_{recovery}$ < 1 second.

Practical Considerations

Timeout Selection:

• Bahut chhota: Valid lambi operations ke dauran false resets
• Bahut lamba: Actual faults se slow recovery
• Rule of thumb: $T_{timeout}$ = nominal loop time ka 2× se 3×

Interrupt vs Reset: Kuch watchdogs interrupt mode offer karte hain: final reset se pehle interrupt generate karo. Isse use karo:

• Debugging ke liye system state log karne ke liye
• Recovery try karne ke liye (stuck peripheral clear karo, state machine reset karo)
• Agar recovery fail ho, hard reset tak progression allow karo

Watchdogs Test Karna: Tumhe ZAROOR test karna chahiye ki watchdog actually kaam karta hai:

void test_watchdog() {
    wdt_enable(WDTO_500MS);
    while(1) {
        // Deliberately don't feed - should reset in 500ms
    }
    // Should never reach here
}

TEST KYUN? Misconfigured watchdog false confidence deta hai. Development mein hamesha verify karo ki yeh trigger hota hai.

Power Consumption: Watchdogs typically independent RC oscillators use karte hain jo sleep modes mein run karte hain. Sleep current mein ~1-10µA add hota hai. Ultra-low-power designs ke liye battery life calculations mein yeh factor karo.

Ek watchdog timer robot ke liye kitchen timer set karne jaisa hai. Tum robot ko batate ho: "Har 5 minute mein, tumhe aake yeh button press karna hai timer reset karne ke liye. Agar bhool gaye, timer BEEP karega aur main tumhe band karke wapas on kar dunga fix karne ke liye."

Ab, jab tumhara robot sahi se kaam kar raha hota hai, har kuch minute mein woh sochta hai "Oh, woh timer reset karna hai!" aur button press karta hai. Timer reset ho jaata hai, aur sab kuch chalta rehta hai.

Lekin agar robot freeze ho jaaye - woh button press nahi kar sakta. Timer countdown karta rehta hai... 4 minute... 3 minute... 2... 1... BEEP! Timer off hota hai, jo automatically robot ko band karke wapas on kar deta hai (jaise plug nikaal ke wapas lagane jaisa). Jab woh restart hota hai, woh frozen nahi hota - problem fix!

Trick yeh hai: robot ko button tab press karna chahiye jab woh actually homework sahi se kar raha ho. Agar woh button press kare jab woh ek bure loop mein stuck ho (jaise ek hi math problem baar baar galat karte rehna), toh isse koi faayda nahi. Toh tum robot ko train karte ho ki button sirf tab press kare jab usne ek complete homework problem sahi se finish ki ho.

Yahi exactly embedded systems watchdog timers ke saath karte hain - yeh ensure karte hain ki computer actually sahi kaam kar raha hai, aur agar freeze ho jaaye, automatically restart kar dete hain!

Connections

• Interrupt Service Routines - Watchdog reset se pehle interrupts generate kar sakta hai
• Real-Time Operating Systems - RTOS task monitoring watchdogs ke saath
• Hardware Timer Peripherals - Watchdog timer hardware use karta hai
• System Reset Sources - Different reset types detect karna aur handle karna
• Fault Tolerance - Watchdog fault-tolerant design ki ek layer hai
• Brown-Out Detection - Power fault protection ke liye watchdog ke saath kaam karta hai
• Safe State Design - Watchdog reset ke baad system behavior
• Bootloader Design - Firmware updates ke dauran watchdog behavior

#flashcards/coding

Watchdog timer kya hota hai? :: Ek hardware timer jo automatically system ko reset karta hai agar software periodically usse "feed" (reset) karna fail kar de, software hangs aur deadlocks se protection provide karta hai.

Hardware-only aur software-controlled watchdog mein kya fark hai? :: Hardware-only ko software dwara disable nahi kiya ja sakta (maximum protection); software-controlled ko runtime par enable/disable kiya ja sakta hai (zyada flexible lekin kam protection).

Concept Map