Skip to main content
Bring up a new board, board revision, or peripheral one observable step at a time. Establish a working build and a way to observe the target, confirm the board’s startup and connections, then verify the first peripheral transaction or output. Start with a small milestone such as a boot message, a device identity read, or a measured GPIO transition. Keep unrelated application changes out of that first check so failures are easier to isolate.

​
Define the milestone

Include the board revision, fitted parts, operating conditions, and result that will count as success. For a board that has never booted, first establish a startup marker or debug connection before attempting the full sensor milestone.

​
Prepare project context

  1. Select the intended project with /project and confirm its platform matches the board.
  2. Add fitted components with /peripheral.
  3. Add the board’s complete schematic set, including power and connector sheets.
  4. Run /init and confirm the build, flash, and observation commands in EMBEDDER.md.
Review suggested parts against the actual board. A catalog match does not establish the populated variant or wiring.

​
Check the hardware assumptions

Confirm the intended supply voltage, reset and boot configuration, clock source, and debug or logging connection. For the first peripheral, check its power sequence, bus pins, pull-ups, chip select or address straps, and any required enable signal against the populated board.
Replace the part and schematic reference with the fitted device and its reference in the active design. Use Plan mode when the result requires architectural choices. Review the plan, then implement the smallest working path in Act mode.

​
Establish a startup baseline

Build the smallest suitable application from the project’s existing SDK or board support. Confirm the artifact and target before flashing. Capture a known boot marker over UART, RTT, or another connection supported by the board.
If there is no marker, check power, reset, clocks, output routing, and the capture settings before adding peripheral code. Opening a UART can change DTR/RTS, and a new debugger connection can program or reset a target; use the connection guide when preserving a failed run matters.

​
Build, flash, and observe

Once startup is established, initialize one peripheral and perform the smallest transaction that proves communication. Prefer a documented identity or status read before enabling a larger workload. Run the intended build and stop if it fails. Confirm the artifact and connected target, then flash and capture the expected output with a timeout.
Check that values are plausible for the test conditions. A successful flash without the expected behavior is an incomplete bring-up.

​
Diagnose before expanding

Use serial output for startup order, a logic analyzer for transactions, an oscilloscope for signal quality, and GDB for state. Run /debug when debugger inspection is needed. Start with the observation that can distinguish the most likely causes. For a missing bus response, first check whether the expected pins toggle. If they do, inspect address or chip-select timing and acknowledgement; if they do not, inspect initialization, clocks, and pin configuration. Repeat the same bounded check after each change. Preserve a fault before resetting the board. See Monitor and debug.

​
Make bring-up repeatable

Save the successful setup in EMBEDDER.md and the test as a hardware script. Record the board revision, firmware artifact, wiring, expected output, and any manual reset or power steps. Re-run the check from the intended startup condition before adding the next peripheral or feature. When the first transaction works, continue with Driver development to build the full interface, error handling, and regression checks.
Last modified on September 12, 2026