> ## Documentation Index
> Fetch the complete documentation index at: https://docs.embedder.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Rapid bring-up

> Take a new board or peripheral from its first build to a verified, repeatable firmware milestone.

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

```text theme={"system"}
Bring up the BME280 on the schematic's I2C bus. Read chip ID, temperature,
and pressure once per second. Build the debug image and verify the ready
message plus three samples over UART.
```

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](/core-concepts/schematics), including power and connector sheets.
4. Run `/init` and confirm the build, flash, and observation commands in [EMBEDDER.md](/core-concepts/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.

```text theme={"system"}
Check the sensor's power-up sequence, I2C address, pull-ups, and pin mapping
against the datasheet and @sch:component:U4. Report unresolved assumptions
before changing the driver.
```

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](/debug-mode/flashing). Capture a known boot marker over [UART](/debug-mode/uart), [RTT](/debug-mode/rtt), or another connection supported by the board.

```text theme={"system"}
Build the minimal startup application for this board revision. If the build
passes, flash the confirmed target and capture its configured boot output
for ten seconds. Report programming success and the boot marker separately.
```

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.

```text theme={"system"}
Build the debug image. If it passes, flash the selected board and capture UART
for 15 seconds. Report the chip ID, ready marker, and three sensor samples.
```

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](/debug-mode/logic-analyzer) for transactions, an [oscilloscope](/debug-mode/oscilloscope) for signal quality, and [GDB](/debug-mode/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](/debug-mode/overview).

<span id="turn-the-prototype-into-a-repeatable-check" />

## Make bring-up repeatable

Save the successful setup in `EMBEDDER.md` and the test as a [hardware script](/debug-mode/hardware-scripts). 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](/solutions/driver-development) to build the full interface, error handling, and regression checks.