The Art of Embedded Board Bring-Up

A box arrives from the fab house. Inside is a stack of freshly manufactured PCBs — your design, realized in copper and silicon. They smell faintly of flux. They are, at this moment, the most expensive paperweights you own.

Board bring-up is the process of turning those paperweights into working systems. After twenty years of doing this — on satellite modems, military SIGINT platforms, biomedical devices, and telemetry units — I can tell you it's equal parts science, art, and profanity.

Here's how it actually works.

Phase 1: Don't Blow It Up

Before you power anything on, you verify you won't destroy it. This isn't paranoia — it's experience. I've seen a reversed polarity protection diode that wasn't in the BOM take out an entire $15,000 prototype run.

Visual Inspection

Magnifying glass or microscope. Check every component against the BOM. Look for solder bridges, missing parts, tombstoned passives, and backwards ICs. The assembler is good, but they're not perfect — especially on Rev A boards with new footprints.

Continuity and Short Checks

Before any power is applied: check every power rail for shorts to ground. Use a multimeter. Check VCC to GND on every voltage domain. If you find a short, find it now — not after you've cooked a regulator.

Power Rail Sequencing

Modern SoCs and FPGAs have strict power sequencing requirements. Core voltage before I/O voltage. PLL supply before digital. Some parts will latch up permanently if you get this wrong. Read the datasheet power-up sequence section three times, then read it again.

Bring up each rail individually with a bench supply and current limiting. Watch the current draw. Know what quiescent current you expect. If the 1.0V core rail is drawing 500mA before the processor is even configured, something is very wrong.

Phase 2: Signs of Life

The board is powered. Nothing is smoking. Time for signs of life.

Clock Verification

Put an oscilloscope probe on every crystal and oscillator output. Verify frequency, amplitude, and stability. Clocks are the heartbeat of every digital system — if the clocks aren't right, nothing downstream will work, and the failure modes will be baffling.

The First UART

The most beautiful moment in board bring-up: the first characters on a serial console. Connect a USB-to-UART adapter, open a terminal at the right baud rate (usually 115200, but check), and power cycle. If you see bootloader output, you're in business.

If you see garbage characters, your baud rate is wrong or your TX/RX are swapped. If you see nothing, the processor isn't executing — go back to clocks and reset circuitry.

JTAG/SWD Connection

Connect your debug probe (J-Link, ST-Link, or FTDI-based). If you can halt the core and read registers, the processor is alive. This is your lifeline for everything that follows. If JTAG doesn't connect, check:

JTAG pins aren't being driven by something else
Reset is properly deasserted
Boot mode pins are set correctly
The debug probe supports the target voltage

Phase 3: Peripheral Bring-Up

Now the systematic work begins. Bring up each peripheral one at a time. Don't try to get everything working simultaneously — that's how you end up debugging three problems at once and solving none of them.

Memory Controller

If you have external DDR, this is often the hardest part. DDR initialization involves dozens of timing parameters that must match your specific memory chips and PCB trace lengths. Use the silicon vendor's memory configuration tool if one exists. If not, prepare for hours with the DDR timing spreadsheet.

Run memory tests — not just a quick read/write, but a proper walking-ones pattern across the full address space. Marginal DDR timing will pass quick tests and fail catastrophically under load.

The Peripheral Checklist

Work through each peripheral methodically:

UART — Already done (hopefully). Test all ports, not just console.
SPI — Connect a logic analyzer. Verify clock polarity/phase (CPOL/CPHA). Talk to a known-good SPI device (flash, ADC).
I²C — Scan the bus. Every device should ACK at its expected address. Check pull-up resistor values — too high and the bus is slow, too low and weak drivers can't pull down.
Ethernet — PHY negotiation first (check link LED), then ping. MDIO configuration must match the PHY's register map. Don't forget the MAC address.
USB — Start with device mode (easier to debug). Host mode adds hub complexity.
GPIO — Toggle every pin, verify with scope. Check for pins that are supposed to be outputs but are stuck (hardware conflict).
ADC/DAC — Apply known voltages, verify readings. Check reference voltage accuracy.
PWM/Timers — Verify frequency and duty cycle with scope.

Phase 4: Operating System

With peripherals validated, it's time to bring up the operating system. The choice depends on the application:

Bare Metal / Super Loop

For simple, single-purpose devices. A main loop with interrupt-driven I/O. Fast startup, deterministic timing, minimal memory footprint. When your MCU has 64KB of flash, this is your only option — and it's a perfectly valid one.

FreeRTOS

The workhorse of embedded RTOS. Lightweight, well-documented, and runs on everything from Cortex-M0 to Cortex-A. Task-based concurrency with priorities, queues, and semaphores. Free (as in beer and speech). I've used it on dozens of products.

Key decisions at bring-up:

Tick rate — 1ms is standard
Heap allocation — heap_4 for most cases
Stack sizes — always bigger than you think. Stack overflows in RTOS are the #1 cause of mysterious crashes

VxWorks

When reliability requirements are non-negotiable — aerospace, defense, medical. POSIX-compliant, deterministic, and certified to DO-178B/C. The BSP development is more involved than FreeRTOS, but you get a battle-tested kernel with decades of heritage in safety-critical systems.

Embedded Linux

When you need the full ecosystem — networking stacks, filesystems, USB device classes, package management. Custom kernel configuration, device tree creation, and root filesystem build (Yocto or Buildroot). Boot time optimization matters — nobody wants to wait 45 seconds for a thermostat to boot.

Phase 5: Integration and Validation

Individual peripherals work. The OS boots. Now make them all work together under real-world conditions.

Thermal Testing

Run the system at full load in a temperature chamber. Watch for frequency throttling, memory errors, and peripheral failures at temperature extremes. The datasheet says -40°C to +85°C, but that assumes perfect layout and decoupling. Your board isn't perfect.

Power Profiling

Measure actual power consumption in every operating mode: sleep, idle, active, peak. Compare to your power budget. For battery-powered devices, this is where you discover that the WiFi module's sleep current is 10x the datasheet value because of a floating enable pin.

EMI Pre-Scan

Before formal compliance testing, do a pre-scan with a near-field probe. Find the noisy spots now, when you can still add ferrites and adjust layouts. Failing EMI at the test lab costs $5,000+ per re-test.

Lessons From Twenty Years

Read the errata. Every silicon has bugs. The errata sheet is as important as the datasheet.
Keep a lab notebook. Document everything — every measurement, every configuration change, every weird behavior. Future you will thank present you.
Current limit everything. Bench supplies should always have current limiting set before power-on. Always.
One change at a time. Change one thing, test, observe. Never change three things and wonder which one fixed (or broke) it.
Trust the scope, not the debugger. When hardware and software disagree, the oscilloscope tells the truth.
The problem is always in the last place you look — because you stop looking. But also, it's usually a ground issue.

The Payoff

There's a unique satisfaction in board bring-up that software-only engineers never experience. You're bridging the physical and digital worlds. When that first UART message prints, when the Ethernet link LED blinks, when the RTOS starts scheduling tasks on hardware you helped design — that's engineering at its most tangible.

If you have a board that needs software, or a design that needs embedded expertise, let's talk. I've been doing this for two decades, across satellite modems, defense platforms, biomedical instruments, and everything in between. And I still get excited when the scope shows a clean clock edge.