In this lesson, you will learn how to evaluate the effectiveness of your watchdog timer (WDT) and error-handling routines when a system encounters a permanent, non-recoverable hardware fault.
The Challenge of Persistent Faults
Up until now, we have practiced injecting transient glitches—like voltage spikes or brief timing violations—that allow a system to eventually recover. However, a persistent fault (such as a permanently shorted communication line or a failed memory block) creates a "death loop." If your system hangs because of a hardware fault and your WDT triggers a reset, the system reboots, hits the same faulty hardware, and crashes again. This is a "reboot storm."
Evaluating Recovery via Controlled Induction
To analyze your recovery architecture, you must induce a permanent failure during a critical task (e.g., initializing a peripheral bus). By forcing a 0x00 or 0xFF state on a data line using your previously learned boundary scan techniques, you can simulate a stuck-at fault.
When the system hangs, your monitoring logic—integrated with your trace macrocell—should capture the state transition leading to the WDT reset. Your error-handling routine must then be sophisticated enough to detect that this is a repeat fault rather than a transient one:
void WDT_Handler(void) {
static uint8_t reset_count = 0;
if (++reset_count > MAX_RETRIES) {
// Enter a safe, minimal state to prevent reboot storms
Disable_Peripherals();
Enter_Low_Power_Halt();
} else {
Perform_System_Reset();
}
}
Analyzing the Recovery Flow
By using your hardware trace stream, you can observe the "Recovery Gap"—the time between the watchdog timeout and the subsequent crash. If the gap decreases with each cycle, your bootloader is likely reaching the faulty hardware earlier or failing more aggressively. A robust system identifies the specific peripheral causing the persistent fault and marks it as "disabled" in non-volatile memory before the next attempt, effectively bypassing the failed component to restore partial system functionality.
Key Takeaway: Successful recovery from persistent faults requires differentiating between transient errors and recurring hardware failures to avoid entering catastrophic reboot cycles.