First Firmware and Hardware Bring-Up Code

• The toolchainA cross-compiler (GCC for ARM, RISC-V or AVR), a build system (CMake or Make), a debug probe interface (OpenOCD or probe-rs), and a debugger (GDB). All of these are open source and all of them work together. Understanding the chain rather than using a vendor IDE's button means you can debug the build when it breaks.
• The linker script and the memory mapThe linker script tells the toolchain where flash and RAM are, where the vector table goes, and how sections are laid out. Bring-up failures that look like 'the chip is dead' are frequently a wrong linker script or a missing vector table. Read yours once, properly.
• Startup code and the vector tableBefore main() runs, startup code sets the stack pointer, copies initialised data from flash to RAM, zeroes the BSS, and optionally configures the clock. If the chip resets in a loop, this is where to look.
• Firmware as a hardware instrumentThe most valuable bring-up firmware is not the application. It is a set of small programs: toggle every GPIO in turn, scan the I2C bus and report addresses, read the flash JEDEC ID, output a known square wave for scope calibration, and report the supply voltages via the ADC. These turn a dead board into a diagnosable one.
• Blink is a system testA blinking LED proves power, reset, clock, at least one GPIO, the flash, the boot process and the toolchain — all at once. Getting to blink is genuinely most of bring-up. If blink works, the remaining problems are localised.
• Debug probe and SWDOpenOCD and probe-rs speak to CMSIS-DAP, ST-Link, J-Link and picoprobe adapters over SWD or JTAG. With a working probe you can halt the core, read memory, single-step and inspect peripheral registers directly — which is how you check whether a peripheral is actually configured the way you think.
• Reading peripheral registers is the ground truthWhen an interface does not work, halt the core and read the peripheral's configuration registers directly against the reference manual. Nine times out of ten the register does not contain what your code intended to write, usually because a clock gate was not enabled or a write was to a shadow register.
• Instrumenting for the scopeToggling a spare GPIO at the start and end of a routine turns an oscilloscope into a profiler. Asserting a GPIO on an error condition turns it into a trigger for capturing intermittent faults, as used in the oscilloscope skill. Design a spare test GPIO onto every board for exactly this.

ProblemYour first prototype has arrived, assembled. What order do you do things in?

1. 1
   Before power: visual inspection under magnification. Check the orientation of every polarised part against the assembly drawing. Check for bridges on fine-pitch parts. This costs ten minutes and saves boards.
2. 2
   Before power: continuity checks. Measure resistance from each supply rail to ground. A short (a few ohms or less) means stop and find it. Typical healthy readings are hundreds of ohms to kilohms depending on the decoupling and the loads.
3. 3
   First power: use a bench supply with a current limit set to slightly above your expected idle current, not a USB port. Ramp the voltage slowly and watch the current. A sudden jump means stop.
4. 4
   Measure every rail with the multimeter at the point of load, not at the regulator. Compare against your power tree. Record the numbers.
5. 5
   Scope the rails: look for oscillation, ripple and startup behaviour. An LDO oscillating at hundreds of kilohertz is invisible on a multimeter and fatal to everything downstream.
6. 6
   Check the clock: scope the crystal (with a 10x probe on the output pin, not the input pin, which the probe capacitance will stop). Confirm the frequency and amplitude.
7. 7
   Check reset: confirm the reset line goes high after the supervisor's timeout, and that the pulse is long enough.
8. 8
   Now attach the debug probe. Can it detect the target? If not, check SWD wiring, target power detection, and that the chip is not in a low-power or locked state.
9. 9
   Run blink. This is the first firmware. If it works, power, reset, clock, boot, flash, one GPIO and your toolchain are all proven.
10. 10
    If blink does not work: halt the core with the debugger. Read the program counter. Is it in the reset handler? In a fault handler? In an infinite loop? This single observation localises the problem immediately.
11. 11
    GPIO sweep: write firmware that toggles every GPIO in turn at a distinct frequency, and probe each pin. This finds unsoldered pins, shorts, and footprint errors in one pass. Record the result for every pin.
12. 12
    I2C scan: write firmware that attempts a read from every 7-bit address and reports which ones ACK. Compare against your address map. A missing device is either not powered, not soldered, has the wrong address, or the bus is broken — and the pull-up measurements from an earlier skill tell you which.
13. 13
    SPI: read a known-constant register. Most flash chips have a JEDEC ID; most sensors have a WHO_AM_I. If the value is wrong but not zero or all-ones, suspect the SPI mode. If it is all zeros or all ones, suspect wiring or chip select.
14. 14
    ADC: measure a known voltage (a divider from the rail) and compare to the calculated value. This validates the reference, the input network and your conversion maths at once.
15. 15
    Record everything in a bring-up log with the board's serial number. The second board will have different problems and you will want the first board's baseline.

AnswerInspect, then check for shorts, then power with a current-limited supply, then measure and scope every rail, then clock and reset, then attach the debugger, then blink. After blink: GPIO sweep, I2C scan, SPI ID read, ADC check. Every step recorded in a log against a board serial number.

Tool: GCC, CMake, OpenOCD or probe-rs, and GDB

• Install the toolchain: the GNU Arm Embedded toolchain (arm-none-eabi-gcc), CMake, and OpenOCD (or probe-rs, which is a modern Rust-based alternative that is often easier to set up).
• Get a minimal project for your target. For RP2040, the Pico SDK is open source and CMake-based; for STM32, use the vendor's CMSIS headers with your own CMakeLists; for AVR, avr-gcc and avrdude.
• Build: cmake -B build && cmake --build build. Read the output. Note the memory usage report — flash and RAM used against available. If this fails, the error is in your toolchain setup, not your hardware.
• Inspect the binary before flashing: arm-none-eabi-size build/firmware.elf shows section sizes. arm-none-eabi-objdump -h shows the section layout. Confirm .text is in flash and .data/.bss are in RAM.
• Connect the probe. Start OpenOCD: openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg (adjust for your probe and target). It should report finding the target and its ID code. If it does not, this is a hardware or wiring problem, not a software one.
• Flash: in another terminal, arm-none-eabi-gdb build/firmware.elf, then 'target extended-remote :3333', 'load', 'monitor reset init', 'continue'.
• Verify blink. If it does not blink, in GDB press Ctrl-C to halt and type 'bt' for a backtrace and 'info registers' to see the program counter.
• Read a peripheral register directly: in GDB, 'x/1xw 0x40014000' (substitute your GPIO controller's address). Compare the value against what the reference manual says it should contain given your configuration code. This is the single most valuable debugging technique in embedded work.
• Write the GPIO sweep diagnostic: a loop that configures each pin as an output and toggles it at a pin-specific rate, with a serial printout of which pin is active.
• Write the I2C scanner: for each address 0x08 to 0x77, issue a zero-length write and report whether it was ACKed. Print the results as a grid.
• Instrument for the scope: add a GPIO toggle at the entry and exit of your I2C transaction routine. Capture it on a logic analyser alongside SDA and SCL, and you can now see exactly how long each transaction takes and correlate firmware to signals.
• Add a GPIO assert on any error return, and use it as an oscilloscope trigger as described in the oscilloscope skill. This closes the loop between the two disciplines.
• Commit all of the diagnostics as a 'bringup' build target so they travel with the board design.

• Getting Started with Raspberry Pi Pico (C/C++ SDK)freedoc~120 minThe SDK itself is open source (BSD). The getting-started document covers the whole open toolchain including CMake, OpenOCD and GDB with a debug probe.
• OpenOCD user guideopen licencedoc~90 minGPL. Read the configuration and the GDB integration chapters. Understanding the config file structure saves hours when a probe does not connect.
• probe-rsopen licencetoolOpen source (Apache/MIT) debug tooling that is often much easier to configure than OpenOCD, with a good CLI and RTT support. Works with CMSIS-DAP, ST-Link and J-Link.
• Your MCU's reference manual, register descriptionsfreedatasheet~90 minYou will read peripheral register descriptions constantly during bring-up. Bookmark the GPIO, clock and the relevant peripheral chapters.

Write a complete bring-up firmware suite for a board (your own if you have one fabricated, otherwise any development board treated as if it were an unknown prototype), and produce a bring-up log that documents the board's verified state.

Deliverables

• A project built entirely with open-source tools (GCC, CMake or Make, OpenOCD or probe-rs, GDB) with the build command documented and reproducible from a clean checkout.
• A memory report from the build showing flash and RAM usage against the device's capacity.
• A blink program, with a written statement of exactly which subsystems its success proves.
• A GPIO sweep diagnostic that exercises every pin and reports which pin is active, plus a captured logic analyser or scope trace of at least eight pins confirming the sweep.
• An I2C bus scanner that reports every responding address, with its output compared against your intended address map, and a captured decode of one scan transaction.
• A SPI device identification routine reading a known-constant register (JEDEC ID or WHO_AM_I) with the expected and actual values shown, plus a captured decode.
• An ADC verification routine measuring a known voltage, with the calculated expected value, the measured value, the error in LSBs, and an explanation of the error's likely source.
• A GPIO instrumentation demonstration: a spare pin toggled around a routine, captured on a logic analyser alongside the bus it instruments, with the routine's execution time measured from the capture.
• A debugger session transcript showing: halting the core, reading the program counter, reading a peripheral register directly, and comparing it against the reference manual's expected value.
• A completed bring-up log, structured as an ordered checklist from visual inspection through to all subsystems verified, with the actual measured values recorded at each step and a board identifier at the top.

Acceptance criteria — how you know it is good enough

• The entire toolchain is open source and the build is reproducible from a clean checkout.
• The GPIO sweep covers every pin, not a sample, and is verified by capture.
• The I2C scan output is compared against an intended address map.
• The SPI identification reads a real constant and the value matches the datasheet.
• The ADC error is quantified in LSBs and its source is reasoned about.
• The debugger transcript shows a peripheral register read compared against the reference manual.
• The bring-up log records measured values, not just tick marks.

If you want to push further

• Add RTT or a semihosting channel for logging without a UART, and use it to stream diagnostic data during bring-up.
• Write a self-test that runs at power-up on every board, checks every subsystem, and reports a pass/fail code on an LED, so production units test themselves.

• I can build, flash and debug firmware with an entirely open-source toolchain.
• I can read the memory map and understand what the linker script controls.
• I halt the core and read peripheral registers rather than guessing at configuration bugs.
• I write diagnostics (GPIO sweep, I2C scan, device ID reads) rather than debugging with the application.
• I instrument firmware with GPIO toggles to make an oscilloscope useful.
• I follow a bring-up order that localises faults instead of powering everything at once.
• I keep a bring-up log with measured values against a board identifier.