Loading page…
Your next page is on its way.
Your next page is on its way.
Firmware / From reset to runtime
Make the hardware run.
Know why it works.
Follow startup, register access, interrupt handling, shared data, first-silicon debug, and device protocols through six practical guides.
See how the guides connect
Select a stage to inspect its input, action, and proof. This is a learning path, not a mandatory hardware execution sequence.
Guide 1 of 6 selected: Boot and reset.
Guide 1 of 6
Capture reset evidence, validate vector entry, initialize memory, bring up clocks, and recover from an unconfirmed image.
Explore this guide →Six guides / Read in order or jump in
Use worked examples, interactive diagrams, and step-by-step labs to connect hardware behavior to firmware decisions.
Establish a valid starting state
Capture reset evidence, validate vector entry, initialize memory, bring up clocks, and recover from an unconfirmed image.
Turn an address into a device operation
Decode addresses and access widths, respect register side effects, and distinguish an issued write from completed device work.
Connect an event to a bounded response
Trace device events through interrupt eligibility, preemption, handler work, DMA ownership, and shared-data handoff.
Make ownership visible
Choose synchronization from the actors and data lifetime. Trace publication, priority inversion, buffer reuse, and overload behavior.
Replace guesses with measured evidence
Check rails, reset, clocks, and debug access. Start with minimal firmware, preserve faults, and change one variable at a time.
Connect devices and decode their traffic
Explore I²C, SPI, UART, JTAG, SWD, USB, Ethernet, CAN/CAN FD, and SD/SDIO through wiring diagrams and step-by-step transactions.
Inside the interrupt guide
Explore hardware sources, pending and active states, preemption, bounded handlers, and shared-data handoffs using the guide’s existing simulations.
Trace the original interrupt system →Apply the reasoning
Practice bounded storage, register side effects, event handling, concurrency, and fault isolation in the question bank.
Firmware is where software meets the physical behavior of a new device. It must establish a trusted boot path, program hardware in the correct order, move data efficiently, and expose enough evidence to debug failures that cross the hardware-software boundary.
Trace a system from reset through drivers and runtime behavior, with attention to ownership, ordering, observability, and failure recovery.
The worked labs state their target and clock assumptions individually. Target-specific cache, DMA, security, and memory-ordering rules still require the device and architecture documentation.