Investigate an unexpected reset
Preserve the first evidence before a reset clears the state that could explain it.
Reset reason first
Read the MCU's reset-cause registers as early as the platform requires. Distinguish power, external, software and watchdog-related causes using the device documentation. A watchdog reset tells you the supervision outcome, not automatically the underlying software defect.
Supervision has a contract
Watchdog supervision may check alive counts, deadlines and logical checkpoint order. A task can execute but report checkpoints incorrectly. Conversely, an alive report can occur while useful application work is wrong. Inspect the configured supervision mode and expected checkpoints.
Retain bounded evidence
Store only well-defined diagnostic context in an appropriate retained region or approved persistent mechanism. Include validity and versioning, and consider power-loss behaviour. Correlate OS errors, traps, stack information and task timing to find the cause.
Follow each transition
Fault occurs
A timing, execution or hardware issue develops.
Conceptual sequence. Timing is slowed for learning; it is not a hardware measurement.
Your investigation
The watchdog reset bit is set. What evidence would distinguish a stalled task from incorrect checkpoint configuration?
Reveal the investigation checklist
- Preserve reset and trap status.
- Trace the supervised task and checkpoints.
- Compare the active supervision mode with configuration.
- Reproduce with the same load and record the first deviation.
A watchdog reset uniquely identifies the original defect. True?
Answer the knowledge check correctly to complete this lesson.
Think through Investigate an unexpected reset
Ask for an explanation, an automotive example or a question that tests your understanding.
Checking mentor availability…