In this lesson, you will learn how to distinguish between a deliberate software-triggered panic and a system-wide hardware watchdog timeout by analyzing the post-mortem status registers.
The Problem of Ambiguous Resets
When a device reboots in the field, the system is usually in a blank slate. If you only see a reset event, you cannot immediately tell if the software hit an assert() (a controlled crash) or if the hardware watchdog (WDT) forcibly terminated execution because the system hung (an uncontrolled crash). To debug this, we must inspect the architecture-specific Reset Status Register (RSR) during the boot sequence before it gets cleared.
Analyzing the Status Registers
Most microcontrollers provide a register that latches the cause of the last reset. For example, in many ARM Cortex-M implementations, this is found in the RCC_CSR (Reset Control and Status Register).
When your firmware boots, you should immediately capture this register and save it to non-volatile memory (or a dedicated "crash area" in RAM) before the system initializes.
void SystemInit(void) {
uint32_t reset_reason = RCC->CSR; // Capture status immediately
if (reset_reason & RCC_CSR_WWDGRSTF) {
// Hardware Watchdog caused the reset (e.g., infinite loop/deadlock)
log_crash("WDT_TIMEOUT", reset_reason);
} else if (reset_reason & RCC_CSR_SFTRSTF) {
// Software-triggered reset (e.g., intentional panic)
log_crash("SW_PANIC", reset_reason);
}
// Clear flags so the next boot starts clean
RCC->CSR |= RCC_CSR_RMVF;
}
Software vs. Hardware Signature
- Software-Triggered Exception: The instruction pointer (PC) at the time of the crash will point inside your panic handler or an error-logging function. You will likely see a clean call stack.
- Hardware Watchdog Timeout: The PC will be "orphaned." Because the WDT triggers asynchronously to the CPU clock, the PC will point to wherever the instruction happened to be when the timer expired. If you see a timeout reset where the PC is in a common background loop or an idle task, it’s a strong indicator that the watchdog expired because a high-priority interrupt or task blocked the main loop indefinitely.
Key Takeaway: Always capture and persist the hardware reset status register during your earliest boot phase to definitively distinguish between intentional software panics and unresponsive hardware watchdog timeouts.