After the record is committedDocumented flag clear
1
Snapshot raw evidence.
Read reset status and the retained boot stage before later startup code can destroy them.
2
Give one reader ownership.
Commit the captured fields to the boot record so later code uses the same evidence.
3
Clear by the target contract.
Follow the documented flag semantics after capture, then use the record to investigate the reset.
ControlNode example. Flags record conditions, not a reliable event timeline. Which domains retain state, and how each flag is read or cleared, remain device-specific.
Mechanism
Separate source from scope
A reset source and the hardware it resets are separate parts of the contract.
DistributionPhysical and software sources route into CPU, peripheral, backup, and debug domains.
RetentionThe core may reset while retained SRAM or an always-on domain survives.
ReviewRecord affected domains for every source; “MCU reset” is too vague.
Evidence
Flags can be simultaneous
Reset flags record observed conditions, not a reliable event timeline.
SemanticsFlags may be sticky, clear-on-read, write-one-to-clear, or lost with their clock domain.
CaptureRead the raw register once before decoding or clearing it.
OrderingUse a retained sequence or timestamp when chronology matters.
Ownership
One early reader owns reset cause
One trusted startup path must own reset evidence.
ReadCapture cause flags, retained boot stage, and reset-loop count.
CommitSave one boot record before the documented clear sequence.
HazardA library that clears first destroys the evidence.
Interactive lab 1 · reset evidence explorer
What survives this reset?
Select a source. The explorer updates the affected domain, raw evidence, first safe action, and the conclusion you must not overstate.
Affected scopeCPU and most peripheral domains reset; backup domain and retained SRAM survive in this lab
First safe actionCopy the raw cause and retained stage into the immutable boot record before clearing the watchdog flag
What it cannot proveThe flag does not prove why software stopped servicing the watchdog or whether another condition preceded it
Checkpoint · 2 easy, 2 medium, 1 hard
Can you preserve and interpret reset evidence?
Easy Why must reset flags be read before normal peripheral initialization?
Initialization code may reset or clock-gate the controller, read a destructive register, or clear sticky flags. The boot owner should capture the raw value first, save it in a boot record, and decode it without rereading a side-effecting register.
What this tests: evidence lifetime and early-startup ownership.
Easy Does a watchdog reset guarantee that the watchdog itself is defective?
No. The watchdog only proves that its service contract was missed. Causes include deadlock, an unbounded clock wait, disabled service code, corrupted control flow, overload, or an incorrectly configured window. Preserve the last boot stage and application heartbeat before forming a hypothesis.
What this tests: separating an observed mechanism from a root cause.
Medium POR and watchdog flags are both set. Which one happened first?
The flags alone may not establish order. A POR flag can remain set across a later watchdog reset if software never cleared it, or both may be latched by a target-defined sequence. Use the manual’s clear/reset rules plus retained sequence numbers or timestamps. Report the ambiguity instead of inventing chronology.
What this tests: combined flags and limits of evidence.
Medium A warm software reset leaves one peripheral active. Is that automatically a hardware bug?
No. The peripheral might reside in a domain excluded from software reset, or its output might be held by an always-on safety block. Compare the reset-domain matrix with the actual source. Startup must either explicitly return that peripheral to a known state or choose a reset source that covers it.
What this tests: reset scope and stale hardware state.
Hard Design a reset record that survives repeated boot failures without treating corrupt retained RAM as truth.
Store a fixed magic, format version, monotonic sequence, raw reset flags, boot stage, selected slot, compact failure code, and CRC in retained memory. Validate magic, bounds, version, and CRC before use. Write the payload first and commit with the sequence or validity marker last. Keep a bounded reset-loop counter and fall back to recovery after the policy threshold.
The record is diagnostic evidence, not an authority for image authenticity. Security decisions still depend on protected counters, authenticated metadata, and target-defined trust storage.
What this tests: retention, torn writes, validation, and recovery policy.
02Vector entry
Boot alias · initial MSP · reset-handler address
The first two words decide whether code can begin.
Reset loads the initial Main Stack Pointer and reset-handler address. A bootloader must recheck both before starting another image.
Word 0
Validate the initial stack
Vector word 0 must describe a usable initial stack.
RegionThe pointer must be in implemented, writable memory and meet alignment.
BoundaryTop-of-RAM may be legal because the stack grows downward.
ExampleFor 0x20000000–0x2003FFFF, use aligned 0x20040000.
Word 1
Validate the executable entry
Vector word 1 must name an allowed executable address in Thumb state.
StateCortex-M requires stored bit 0 to be 1.
RangeMask bit 0 before checking the executable image region.
Example0x08004101 names code at 0x08004100 in slot A.
Handoff
Relocation is a separate decision
Hardware reset entry and a later bootloader handoff are different operations.
QuiesceStop activity still owned by the bootloader.
TransferSet the vector base, load the application MSP, then branch.
FailureA wrong VTOR may fail only on the first exception.
Interactive lab 2 · reset-to-C stepper
Walk the first seven stages and inject one fault.
Choose an image defect, then advance the sequence. The model stops at the first unsupported stage.
1Reset release
2Boot alias
3Load MSP
4Load PC
5Reset_Handler
6Runtime init
7Application entry
Stage 1 of 7 · reset releaseProcessor reset is released on the safe internal clock
No C object exists yet. Only architectural reset state and target boot selection are available.
Validation resultPASS · advance to the target-defined reset alias
Checkpoint · 2 easy, 2 medium, 1 hard
Can you prove the first branch is legal?
Easy What do vector-table words 0 and 1 represent on Cortex-M?
Word 0 supplies the initial Main Stack Pointer. Word 1 supplies the reset-handler address, including the Thumb-state indicator in bit 0. They are data consumed by reset entry, not ordinary instructions executed in place.
What this tests: the architectural reset model.
Easy Why is 0x08004100 an invalid stored reset vector for this Cortex-M example?
Bit 0 is clear. Cortex-M executes Thumb instructions, so a callable vector value must have the state bit set, such as 0x08004101. Range checks should compare the masked address 0x08004100 with the image’s executable region.
What this tests: entry encoding versus instruction address.
Medium Is 0x20040000 outside a 256 KiB SRAM beginning at 0x20000000?
It is the exclusive upper bound of that range, so it cannot be dereferenced as an SRAM byte. It can still be a valid empty descending-stack pointer because the first push decrements the pointer into valid SRAM. The bootloader must also check alignment and reserve enough stack below it.
What this tests: bounds, exclusive ends, and descending-stack semantics.
Medium The application starts but faults on the first timer exception after an A/B handoff. What boot evidence is most relevant?
Inspect the selected slot, application vector base, and VTOR value at handoff. A stale VTOR can leave straight-line code working while later vector lookup uses the bootloader or other slot’s table. Also verify that the selected table is aligned and lies in implemented VTOR address bits.
What this tests: separating initial branch success from exception-vector relocation.
Hard Specify a safe bootloader-to-application handoff contract.
Validate authenticated image metadata, vector-table bounds, initial MSP range/alignment, executable reset entry, and target policy. Stop bootloader-owned producers, clear or transfer pending state according to the platform contract, restore expected clock/cache/MPU state, set the application vector base where implemented, load the application MSP, and branch to its reset entry without returning.
The exact interrupt and peripheral cleanup is target-specific. The application and bootloader must share a written interface contract rather than each assuming reset defaults.
What this tests: cross-image state ownership and defensible handoff.
03C runtime
Linker contract · sections · one startup owner
C starts only after firmware constructs its memory model.
Startup turns linker-defined sections into valid C/C++ state. Each initialization job must have one owner.
C runtime · memory movement
Three sections, three startup actions.
.data12 KiB · copyFlash load image→Writable SRAM
.bss28 KiB · zeroNo flash payload→Zeroed SRAM
.noinit4 KiB · validateRetained bytes→Preserve, then check
.data · copy 12 KiB
Action
Copy the initialized bytes from their flash load address to their writable SRAM run address.
Evidence
Match load, start and end symbols to the linker map; one startup path owns this copy.
Boundary
The 12 KiB range belongs to this ControlNode example. Use the actual image's linker symbols.
Skipping .noinit during zeroing does not guarantee retention across power loss. Validate magic, version, bounds and checksum before use. GNU ld: load and run addresses.
Placement
Know load address versus run address
The linker script defines where bytes live in the image and where they run.
Flash.text and .rodata usually stay in flash.
Initialized data.data has a flash image and a writable SRAM address.
Zero data.bss is created in SRAM; confirm every range in the linker map.
Retention
Exclude .noinit deliberately
Retained state is skipped by normal zeroing, not automatically trusted.
PlacementPut crash records and breadcrumbs in a dedicated linker section.
ValidationCheck magic, version, bounds, and checksum on every boot.
ThreatsPower loss, debugger writes, or older firmware may leave arbitrary bytes.
Ownership
Choose one runtime path
Use the toolchain startup path or custom section loops, never both.
ToolchainCMSIS commonly calls SystemInit(), then __PROGRAM_START().
Custom pathAssembly may instead own section copy and zero operations.
OwnershipDocument who owns clocks, memory, constructors, and application entry.
Worked contract · inspect the map, then the loops
ControlNode runtime construction
Section
Load address
Run address
Startup action
Lab size
.text/.rodata
Flash
Flash
No copy
180 KiB
.data
Flash image
SRAM
Copy exactly 12 KiB
12 KiB
.bss
None
SRAM
Zero exactly 28 KiB
28 KiB
.noinit
None
Retained SRAM
Preserve, then validate
4 KiB
Stack reserve
None
Top of SRAM
Set bounds and monitor
16 KiB
/* Conceptual startup. Use toolchain-provided symbols and ABI. */
copy_words(&__data_load, &__data_start, &__data_end);
zero_words(&__bss_start, &__bss_end);
validate_retained_record(&boot_record); /* .noinit */
__PROGRAM_START(); /* constructors, then main */
Worked timing assumption40 KiB of copy plus zero work ÷ an illustrative 20 MiB/s effective startup rate = about 2.0 ms
This is a lab estimate, not an architectural guarantee. Flash wait states, bus width, loop implementation, ECC, caches, and debugger state can change the measured rate.
Checkpoint · 2 easy, 2 medium, 1 hard
Can you reconcile the image, linker map, and startup code?
Easy Why does initialized .data need both a load and run address?
Its initial bytes must live in nonvolatile storage so they survive power loss, but C code needs the objects in writable SRAM at runtime. Startup copies from the flash load image to the SRAM run range before those objects are used.
What this tests: image storage versus runtime placement.
Easy Why does the binary not need to store every zero in .bss?
The image records the section’s address and size. Startup creates its required all-zero initial state in SRAM. Omitting explicit zero bytes reduces stored image size while preserving the C initialization contract.
What this tests: section semantics and image footprint.
Medium The map shows 12 KiB of .data and 28 KiB of .bss. At an assumed effective 20 MiB/s, what is the idealized construction time?
The work is 40 KiB. Using binary units, 40 × 1024 / (20 × 1024 × 1024) = 0.001953125 s, about 1.95 ms. Round to roughly 2.0 ms, then measure the real implementation and include margin in the watchdog budget.
What this tests: units, idealized throughput, and measurement discipline.
Medium A retained crash record becomes “valid” after a firmware downgrade. What is missing?
A CRC alone can accept an older but structurally different record. Include a format version and length, validate every field and enum, and define compatibility policy. Clear or migrate incompatible records before application code consumes them.
What this tests: retained-data versioning and semantic validation.
Hard Constructors execute twice after a startup refactor. How do you localize the owner conflict?
Trace from the vector’s reset handler through SystemInit(), custom section loops, the toolchain entry, constructor-array walkers, and main(). Use the link map and disassembly to find both calls. Then choose one documented runtime owner and remove the duplicate path, preserving required ABI setup.
Add a startup test object whose constructor increments a retained or probe-visible counter exactly once. Verify cold boot, warm reset, bootloader handoff, and debug reset.
What this tests: startup call graph, ABI ownership, and regression checks.
04Clock tree
Safe source · voltage · flash latency · bounded waits
Increase performance only after its dependencies are ready.
Start on a safe clock, prepare voltage and flash first, verify each transition by a deadline, and keep a fallback.
Clock tree · rate and readiness
80 MHz needs more than arithmetic.
Source8MHz
÷1 ×20
VCO160MHz
÷2
CPU80MHz
Example calculation: 8 ÷ 1 × 20 ÷ 2 = 80 MHz. Check input, VCO and output limits separately.
1
Prepare the operating point.
Stay on a safe source while voltage and flash timing become ready for the target frequency.
2
Wait with a deadline.
Start the source and PLL; a bounded lock wait must have a safe timeout path.
3
Switch and prove.
Read back the selected source and update dependent timing. A programmed divider is not proof of an active clock.
ControlNode example, not a universal PLL configuration. Use the target manual for legal frequencies, voltage and flash settings, status flags, and the required sequence.
Dependency order
Prepare before switching
Clock startup is an ordered dependency chain, not a register dump.
UpshiftPrepare voltage and flash, start the source, lock the PLL, then switch.
DownshiftThe safe order may reverse when reducing frequency.
AuthorityFollow the target manual; there is no universal sequence.
Calculation
Check every PLL node
A valid CPU frequency requires every internal PLL node to remain legal.
EvidenceRead the selected-source status, measure a divided clock output, and derive a timer period from the measured frequency
Failure avoidedRunning flash above the configured latency or waiting forever for a source that never stabilizes
Checkpoint · 2 easy, 2 medium, 1 hard
Can you bound startup without violating a frequency dependency?
Easy Why set flash wait states before raising the CPU clock?
Flash access time may not meet the shorter CPU cycle at the higher frequency. Preparing latency first keeps instruction fetches within the target’s timing specification during and after the switch.
What this tests: dependency ordering and transient safety.
Easy What is wrong with while (!PLL_LOCKED) {} in boot code?
It has no bound. A missing crystal, invalid configuration, or damaged oscillator can trap every boot and eventually trigger an opaque watchdog reset. Use a time base independent of the unproven clock, record the failed stage, and enter a defined fallback.
What this tests: bounded waits and recovery.
Medium Calculate the ControlNode CPU clock for 8 MHz, M=2, N=24, P=2.
fVCO = 8 MHz ÷ 2 × 24 = 96 MHz. Then fCPU = 96 MHz ÷ 2 = 48 MHz. The arithmetic does not prove legality; check the PLL input and VCO ranges, voltage range, flash latency, and divider encodings.
What this tests: formula use plus constraint awareness.
Medium The crystal fails but the internal oscillator works. What else changes besides CPU speed?
Recalculate every derived peripheral clock and timing contract: UART baud, timer periods, watchdog source, flash programming timing, communication tolerances, and any certified control loop. Publish degraded-clock status so the application can disable features whose accuracy or throughput is no longer valid.
What this tests: clock-tree propagation and degraded-mode design.
Hard Set a watchdog boot budget when crystal startup is specified as 10 ms maximum, PLL lock as 2 ms maximum, runtime construction measures 2.3 ms worst case, and image verification measures 14 ms worst case.
The named maxima total 28.3 ms. Add measured control overhead and a justified environmental/production margin, then choose a representable watchdog window above that bound, for example 40 ms only if target and product analysis support the margin. Service the watchdog at explicit phase boundaries or use one whole-boot window, according to the safety contract.
Do not hide an unbounded operation by feeding the watchdog inside a polling loop. Record phase timing and fail to recovery when a phase exceeds its own deadline.
What this tests: worst-case arithmetic, margin, and meaningful watchdog service.
05Image recovery
Manifest · authenticity · trial · rollback
A valid checksum is not a trusted or bootable image.
Boot only images that pass bounds, vectors, authenticity, compatibility, version, and slot-state checks. Trial boot comes before confirmation.
Validation layers
Structure before cryptography
Reject malformed images before hashing or signature verification.
BoundsKeep the header, signed regions, vector table, and entry inside the slot.
TrustVerify the authenticated manifest and image with a protected trust anchor.
CRCA checksum detects corruption; it does not prove authorization.
Policy
Compatibility and rollback matter
A valid signature does not prove that an image fits this device or permitted version.
CompatibilityAuthenticate the board revision and required hardware.
VersionEnforce a monotonic minimum security version.
StorageProtect the rollback counter; a nearby flash flag is not authoritative.
Recovery
Trial is not confirmation
A trial image remains provisional until application health is committed.
AttemptsReset before confirmation consumes an attempt or rejects the trial.
ConfirmCommit only after critical self-tests and persistent services succeed.
MetadataUse redundant records, sequences, CRCs, and commit-last writes.
Interactive lab 4 · A/B boot-slot state machine
Step a candidate image through install, trial, confirmation, or rollback.
Select a failure story, then advance the persistent metadata one transition at a time.
EMPTYVALIDTRIALCONFIRMEDREJECTED
Transition 1 of 4 · candidate validatedSlot B is VALID; slot A remains CONFIRMED
The complete candidate fits its slot, passes structural and vector checks, and its authenticated manifest is accepted. It has not run yet.
Power-loss invariantAt least one previously confirmed image remains selectable throughout the update
Next boot decisionCommit the TRIAL record last, then boot slot B with a bounded attempt counter
Checkpoint · 2 easy, 2 medium, 1 hard
Can you keep one recoverable, authorized image?
Easy What does a CRC prove, and what does it not prove?
A suitable CRC is useful for detecting accidental bit errors against an expected value. It does not prove the identity or authorization of the image author because an attacker can modify both image and CRC. Authenticity requires a cryptographic verification rooted in protected trust material.
What this tests: integrity-detection versus authenticity.
Easy Why keep the previous slot after the new image first boots?
Passing static validation does not prove the new image can initialize hardware, migrate state, communicate, or remain alive. The old confirmed slot provides recovery until the trial image completes defined health checks and commits confirmation.
What this tests: install success versus runtime success.
Medium Power fails halfway through programming slot B. What should the next boot do?
Slot B must remain EMPTY or invalid because its commit metadata was never completed. The bootloader validates metadata records, ignores the incomplete candidate, and boots the still-confirmed slot A. It may resume or restart download later according to policy.
What this tests: commit-last metadata and power-loss invariants.
Medium A signed image has version 18 while the protected minimum is 21. Should it boot?
Not under a policy that enforces minimum security version 21. A valid signature establishes an authorized publisher, but anti-rollback policy independently rejects an older vulnerable version. Recovery exceptions, if any, must be explicit and protected.
What this tests: authenticity versus version policy.
Hard Design confirmation so power loss cannot leave both slots unbootable.
Keep slot A’s CONFIRMED record unchanged while B is VALID or TRIAL. Write B’s new metadata into an inactive redundant record with higher sequence, payload, CRC, and final commit marker. After B meets health criteria, atomically select its committed CONFIRMED record. Retire A only in a later transaction after B is independently recoverable.
On boot, validate both record copies and choose the highest valid sequence allowed by policy. A torn new record is ignored. Define attempt counters and a REJECTED transition without erasing the last confirmed image.
What this tests: redundant metadata, ordering, and whole-update invariants.
06Startup evidence
Deadlines · breadcrumbs · recovery
Turn every silent reset loop into bounded evidence.
Give every startup stage a deadline, observable checkpoint, and fallback so the next reset explains where progress stopped.
Breadcrumbs
Commit the next stage before entering it
Write a stage-enter marker before each risky operation.
RecordStore a compact stage identifier and sequence in validated retained storage.
InterpretationAfter reset, the marker identifies the operation that did not finish.
MediumKeep writes bounded and compatible with the storage technology.
Measurement
Separate hardware and software evidence
Electrical and software evidence complement each other; neither proves the whole boot alone.
ProbeObserve reset release, early GPIO, clock output, handoff, and confirmation.
IntrusionA debugger halt changes timing and sometimes reset behavior.
AutonomousPreserve trace or retained records for failures that vanish under halt.
Recovery
Detect loops, then change the path
Recovery must change at least one condition after repeated failure.
ThresholdStop retrying after a bounded failure count.
AlternativesChoose a safe clock, confirmed image, safe mode, or immutable recovery.
ReportPublish the selected recovery path and its reason.
Synthesis capstone · complete boot contract
ControlNode startup evidence sheet
Each row names an owner, pass condition, deadline, evidence, and fallback. Replace every lab value with measured target data before using this pattern in a product.
Gate
Owner
Pass condition
Lab deadline
Evidence
Fallback
Reset capture
Early boot
Raw flags and retained record copied before clear
0.2 ms
Boot record sequence
Mark evidence invalid, continue conservatively
Image selection
Bootloader
One policy-allowed slot has valid committed metadata
1.0 ms
Slot and metadata sequence
Immutable recovery
Image verification
Bootloader
Bounds, vectors, signature, compatibility, version pass
Whole-boot lab bound0.2 + 1.0 + 14 + 3 + 13 = 31.2 ms before application health monitoring begins
InvariantNo unbounded wait, destructive evidence read, unauthenticated jump, or trial confirmation occurs outside a named owner and recovery transition
BoundaryException priority, masking, ISR response, and DMA-completion mechanics remain in the companion interrupts guide
Checkpoint · 2 easy, 2 medium, 1 hard
Can you defend the complete startup path?
Easy What makes a useful boot breadcrumb?
It is written before entering a risky stage, survives the relevant reset, has a version and integrity check, and maps to one unambiguous operation. “Boot failed” is weak; “entered PLL-lock wait, sequence 42” narrows the next experiment.
What this tests: observability with minimal early dependencies.
Easy Why can a debugger make a reset-loop bug disappear?
Halting may freeze watchdogs, extend oscillator startup time, alter boot straps or reset type, preserve debug-domain state, and change timing. Reproduce autonomous power-on behavior with external probes and retained records before relying on a halted snapshot.
What this tests: measurement intrusion and reset conditions.
Medium The retained stage says “VERIFY_IMAGE,” but verification normally takes only 14 ms and the watchdog is 40 ms. What do you inspect next?
Confirm the watchdog’s actual clock and window, then instrument verification sub-stages: header bounds, hash progress, signature operation, trust-store access, and flash reads. Check whether an input length can exceed the slot, whether the crypto accelerator clock is enabled, and whether the measured path differs from the assumed image.
What this tests: turning a breadcrumb into discriminating measurements.
Medium How do you detect a boot loop without counting normal user resets as failures?
Combine reset cause, last committed boot stage, image/slot identity, and an application confirmation marker. Increment a bounded failure count only when reset occurs before the expected stage completes or while a trial remains unconfirmed. Clear or decay it after a confirmed healthy interval according to policy.
What this tests: classification and persistent state transitions.
Hard A production unit intermittently resets between clock switch and application confirmation. Give a highest-information experiment plan.
First preserve raw reset flags, stage sequence, selected slot, clock status, and watchdog timing in the boot record. Probe reset, a divided clock output, supply rail, and stage GPIO without halting. Compare cold/warm reset, internal/external clock, confirmed/recovery image, and minimum/maximum environmental conditions one variable at a time.
Rank hypotheses from evidence: rail droop, oscillator/PLL loss, invalid flash timing, watchdog expiry, runtime corruption, or application failure. Choose the cheapest measurement that separates the top candidates. After the fix, add an automated power-cycle and clock-fault regression that asserts bounded recovery and a valid final boot record.
What this tests: integrated evidence, hypothesis ranking, and regression closure.
Primary references
Verify architecture, toolchain, target, and update policy separately.
