RESET CAUSE
Read the reset-status hardware before initialization destroys context.
Many microcontrollers expose reset-cause flags that can distinguish power-on reset, brownout, watchdog, external reset pin, software-requested reset, lockup, low-power wake, or other device-specific causes.
Those flags often have sticky or clear-on-write behavior. Startup code should capture them early, before generic board initialization clears the register or a library performs another reset-domain action. Store the raw hardware value as well as any human-readable interpretation so later firmware revisions can reinterpret old records if needed.
CRASH STATE
Fault handlers can preserve a compact signature before reset.
On architectures that expose fault status, exception number, stack frame, program counter, link register, or similar state, a fatal handler can copy a bounded crash record into retained RAM or nonvolatile storage before triggering reset.
The handler should remain brutally simple. It may be running with corrupted stack state, interrupts disabled, or a damaged subsystem. Avoid elaborate logging stacks. Capture the smallest high-value record, protect it with a checksum, then reset or enter the defined safe state.
RETENTION RAM
Not every reboot erases every byte.
Some systems provide backup SRAM, retention RAM, RTC-backed registers, or other memory domains that survive selected resets while disappearing on full power loss. These are excellent places for short-lived diagnostic state such as last boot stage, crash reason, or watchdog owner.
Retention memory needs a validity marker and checksum because surviving a reset does not automatically make its contents trustworthy. Define which reset classes preserve the domain and initialize it explicitly after true power-on.
BOOT ATTEMPTS
One failure is an event. Ten failures in thirty seconds is a mode.
Count consecutive unsuccessful boots across resets. Clear the counter only after the application reaches a defined healthy milestone. If the count exceeds a threshold, change behavior: enter safe mode, roll back firmware, disable a suspect subsystem, preserve more diagnostics, or wait for service input.
This prevents infinite reboot loops from masquerading as automatic recovery. It also keeps a failed peripheral or corrupted configuration from repeatedly exercising the same destructive startup path forever.
PROGRESS MARKERS
“Died during boot” is too vague to be useful.
Write a small monotonic stage identifier as startup crosses meaningful boundaries: bootloader verified image, clocks stable, storage mounted, configuration validated, critical buses initialized, network ready, control loop armed, application healthy.
The next boot can inspect the last completed marker. If every failure stops after storage mount, the search space narrows immediately. The marker should be cheap enough to update safely and designed with flash wear in mind. Retained RAM may be preferable for high-frequency progress state, with nonvolatile escalation only after repeated failures.
BROWNOUT
Reset cause is stronger when paired with rail evidence.
A brownout flag says the supervisor observed undervoltage. It does not tell you which load event caused it or how low the rail went. If hardware permits, pair reset cause with minimum-voltage capture, power-good history, battery state, charger state, or a small external supervisor/event latch.
Even without analog history, correlating brownout resets with last system activity can be revealing: radio transmit, motor start, flash erase, USB connection, thermal throttling, or source switchover.
WATCHDOG OWNER
Record who failed to make progress.
If a supervisory task services the hardware watchdog only after several subsystems report health, preserve which subsystem failed the liveness vote and which heartbeat sequence was last observed.
A bare “watchdog reset” is much less useful than “watchdog reset because control task missed three deadlines while communications and storage remained healthy.” This turns a generic reset mechanism into diagnostic evidence about progress.
IMAGE STATE
Firmware version belongs in every boot record.
Record bootloader version, selected application image, candidate/confirmed state, slot, rollback reason, configuration schema version, and relevant hardware revision. A field failure without version context becomes a historical guessing game as soon as devices diverge.
For A/B update systems, repeated reverts should be visible as a first-class event rather than hidden behind the fact that the device eventually booted an older image successfully.
WRITE BUDGET
Do not wear out flash while documenting a reset loop.
Durable telemetry has to survive the failure pattern it records. A crash loop that writes a full diagnostic record on every reboot can rapidly consume one flash sector's endurance.
Use retained memory for frequent transient state, append-only records, bounded ring buffers, event coalescing, rate limits, and wear-leveled storage. Preserve the first failure and important state transitions rather than enthusiastically writing the same fact ten thousand times.
CLOCKS
Timestamp quality after reset may be weak.
A device can reboot before its wall clock is synchronized. If boot telemetry records timestamps, preserve the clock basis: RTC time, monotonic uptime, network-synchronized UTC, GPS, or unknown. A reset record with an uptime counter and sequence number can still be ordered even when civil time is unavailable.
This is the same principle used in public-record chronology: a precise number is not meaningful until the clock that produced it is identified.
MINIMUM RECORD
A tiny record can answer a lot.
A practical compact boot record might contain:
sequence · reset cause · bootloader/image version · boot-attempt count · previous progress marker · crash/fault code · watchdog owner · power state · thermal state · clock basis/time · checksum.
The exact fields depend on the machine. The objective is not to log everything. It is to preserve the facts most likely to distinguish competing explanations after the destructive act of reset.
FIELD METHOD
Prove the black box survives the accidents.
1. Force every reset source. Power-on, external, software, watchdog, brownout, and architecture faults where safely possible.
2. Verify reset flags are captured before being cleared.
3. Crash at different boot stages. Confirm progress markers identify the boundary.
4. Create a reboot loop. Ensure repeated failures escalate and do not destroy storage endurance.
5. Test firmware rollback. Preserve the candidate and revert reason.
6. Remove wall-clock synchronization. Confirm sequence/monotonic evidence still orders events.
7. Power-cycle fully. Know which evidence survives reset only and which survives total power loss.
BOTTOM LINE
Recovery should preserve the reason recovery was necessary.
The boot path is one of the few moments when the system can reliably inspect reset hardware, retained state, update state, and previous progress before ordinary initialization overwrites them.
A reboot that fixes the machine but destroys the diagnosis has only solved half the problem.
SOURCE TRAIL
Technical starting points.
MCUboot — image, boot, confirmation, and revert state
Arm — Cortex-M fault handling concepts