Hardware Bring-Up Checklist: What to Test Before Writing Firmware

You just spent three hours debugging a driver that wouldn’t initialize, rewriting code, scrutinizing register maps, questioning your career choices, only to discover the USB cable on your desk is charge-only. No data lines. The chip was never even being programmed.

This happens constantly to software developers entering the embedded world. You’re used to environments where the “hardware” just works: your laptop boots, your browser opens, your compiler compiles. A dev board sitting on your desk looks equally trustworthy. It isn’t. Boards arrive with ESD damage from shipping. Headers have solder bridges from the factory. Jumpers ship in non-default positions. And yes, half the USB cables in your drawer are missing data lines.

Hardware bringup is the embedded equivalent of running npm install && npm run build before writing application logic. You’re verifying the environment before you touch business logic. On a dev board (an STM32 Nucleo, ESP32 DevKit, nRF52 DK, or Arduino) this takes 15 to 30 minutes. Skip it, and you’ll spend hours trapped in a debugging loop where you can’t tell if the bug is in your code or your circuit.

This article gives you a sequential, tool-agnostic checklist for PCB validation on dev boards and eval kits. Custom PCB bringup is a bigger, harder topic for another day. This is the starter version, and it’ll save you more time than you expect.

The Only Tools You Need

You don’t need an oscilloscope. You don’t need a logic analyzer. You need three things:

A multimeter. This is a handheld device that measures voltage, resistance, and continuity (whether two points are electrically connected). A $25 model like the Aneng AN8008 or a UNI-T UT61E is more than enough. Today you’ll only use two functions: DC voltage measurement and continuity mode. Think of it as your hardware console.log. It tells you what’s actually happening on the wire.

A known-good USB cable with data lines. Many cables bundled with phone chargers carry power only. Before you touch your dev board, plug the cable into your computer and a phone. If the phone shows up as a file transfer device, the cable has data lines. Label it. Guard it with your life.

The board’s documentation. Specifically: the quick-start guide, the schematic, and the board user manual. These tell you where test points are, what default jumper positions should be, and which pins map to what. Read the quick-start guide. It’s four pages. It’ll answer half your questions before you ask them.

Optional: a magnifying glass or your phone’s camera zoom for inspecting solder joints. These are your debugging tools, the same way a browser dev console is for web development.

Step 1: Visual Inspection — Look Before You Power

Before any electricity flows, use your eyes.

Pick up the board and look for obvious physical damage: bent header pins, missing components (empty solder pads where a chip should be), solder bridges between adjacent pins, scorch marks, or cracked components. Flip it over and check the bottom too.

Check that all jumpers and switches are in their default positions. Your board’s user manual has a diagram showing this. On an STM32 Nucleo, for example, the jumpers JP1, JP5, and JP6 configure power source and ST-Link behavior. Wrong positions mean wrong behavior, not broken hardware.

Verify the board revision printed on the silkscreen matches the documentation you downloaded. A “Rev B” board running “Rev C” instructions can have different pin mappings.

⚠️ If anything looks burned, smells burned, or shows discoloration around components, do NOT power it on. You risk damaging your computer’s USB port or the board itself. Contact the vendor for a replacement.

Step 2: Power Rail Validation — The Foundation of Everything

A power rail is a shared wire that supplies a specific voltage to many components on the board. Think of it like a power bus: if the bus is dead, every passenger (chip) on it goes nowhere. If the voltage is wrong, chips behave erratically or not at all.

Plug in your USB cable. Does a power LED light up? Most dev boards have one. If it does, you have a basic sign of life. If it doesn’t, check: Is the cable data-capable? Is the USB port powered? Is a power-selection jumper in the wrong position?

Grab your multimeter. Set it to DC voltage (often labeled V⎓ or VDC). You’re going to measure the voltage rails against ground. Find the 3.3V and GND pins on your board, usually labeled on the silkscreen or documented in the schematic. Touch the red probe to 3.3V, the black probe to GND, and read the display.

Here’s what “good” looks like:

If the voltage is zero, way off, or fluctuating wildly, stop here. Triage: try a different USB cable, avoid unpowered USB hubs (they often can’t supply enough current), double-check jumper configurations, try a different USB port. If nothing works, the board may be dead on arrival. It happens.

If power is wrong, nothing else matters. Every subsequent step assumes clean, stable power rails. This is your foundation.

Step 3: Debugger and Programmer Connection

Most modern dev boards include an onboard debugger: an ST-Link on STM32 Nucleos, a J-Link OB on Nordic DKs, or a CMSIS-DAP on others. You do NOT need to buy a separate $50 debug probe yet. The board has one built in.

Connect your USB cable (the same one; it carries both power and debug data on most boards). Open your IDE or command-line tool: STM32CubeIDE, Arduino IDE, VS Code with PlatformIO, or a terminal with OpenOCD.

The goal is simple: can your computer talk to the chip?

In OpenOCD, this looks like:

openocd -f board/st_nucleo_f4.cfg

A success message includes the target voltage and chip ID:

Info : Target voltage: 3.259763
Info : stm32f4x.cpu: hardware has 6 breakpoints

A failure looks like:

Error: open failed
Error: unable to find CMSIS-DAP device

Think of this as verifying your SSH connection to a remote server before deploying code. If you can’t connect, you can’t deploy.

Common failure modes: missing USB drivers (especially on Windows; install ST-Link drivers or J-Link software), wrong COM port selected, or the board stuck in a non-standard boot mode. Check your board’s docs for boot pin/switch positions.

The key milestone: if you can read the chip ID, the entire path from your computer through the debugger to the MCU is alive. That’s a big deal.

Step 4: The Blink Test — Your Embedded “Hello, World”

The LED blink test isn’t real firmware. It’s a hardware validation tool disguised as a beginner project. Here’s what a passing blink test actually proves:

• The flash/download path works (your code made it onto the chip)
• The MCU boots and executes instructions
• The system clock is running
• At least one GPIO pin toggles correctly

Flash the vendor-provided blink example first. Don’t write your own yet. Every dev board ships with one. If you need to write it, here’s the essence in pseudocode:

void main(void) {
    configure_pin(LED_PIN, OUTPUT);
    while (1) {
        set_pin(LED_PIN, HIGH);
        delay_ms(500);
        set_pin(LED_PIN, LOW);
        delay_ms(500);
    }
}

Pass criteria: the LED blinks at roughly the rate you expect (1 Hz for 500ms on/off). If it’s dramatically too fast or too slow, your clock configuration may be wrong. The chip might be running from an internal RC oscillator instead of the external crystal. Note it and move on; you’ll fix this when you configure clocks properly.

If it doesn’t blink at all: re-check power, re-check the debugger connection, confirm you selected the correct target MCU in your IDE (choosing an STM32F411 when you have an STM32F401 will fail silently).

Step 5: UART Loopback — Your First Communication Sanity Check

UART is a serial communication protocol. Think of it as the console.log of embedded development. Once it works, you have a debug channel for printing values, status messages, and error codes from your firmware.

The loopback test validates that the UART peripheral and its physical pins work without needing any firmware UART code running on the MCU. Here’s how:

1. Find the TX and RX pins for a UART peripheral on your board (check the pinout diagram).
2. Connect TX directly to RX with a jumper wire. You’re sending data out of the transmitter straight back into the receiver.
3. Open a terminal emulator on your computer: PuTTY (Windows), minicom (Linux/Mac), or Arduino Serial Monitor.
4. Configure it for 115200 baud, 8N1: 115,200 bits per second, 8 data bits, no parity, 1 stop bit. This is the de facto default in embedded.
5. Type something. If you see exactly what you typed echoed back, the UART path is proven.

What you’ve validated: the UART peripheral configuration, baud rate settings, pin muxing (the chip’s internal routing of the UART signal to the physical pin), and the physical pin integrity.

This is the bridge between hardware bringup and real firmware development. You now have a way to get information out of the chip, which means you can debug everything that comes next.

The Printable Hardware Bringup Checklist

Save this. Print it. Use it every time you unbox a new board.

1. ☐ Visual inspection — No bent pins, missing parts, solder bridges, or burn marks
2. ☐ Jumpers and switches — All in default positions per documentation
3. ☐ Board revision — Matches downloaded docs and schematic
4. ☐ USB cable verified — Confirmed data-capable (file transfer test)
5. ☐ Power LED — Illuminates on USB connection
6. ☐ 3.3V rail measured — Within 3.14V–3.47V
7. ☐ 5V rail measured (if applicable) — Within 4.75V–5.25V
8. ☐ Debugger detected — IDE or OpenOCD reads chip ID successfully
9. ☐ Blink test passed — LED toggles at expected rate
10. ☐ UART loopback passed — Transmitted string received back intact

For custom PCBs, this checklist expands to 30+ items covering individual power sequencing, clock verification with an oscilloscope, and per-peripheral validation. That’s a different guide for a different day.

What You’re Ready to Build

If all ten items above pass, you’ve established something that most beginner embedded developers never bother to confirm: the hardware works. Your power is clean, your debugger talks to the MCU, your chip runs code, and you have a serial debug channel.

From this point forward, when something doesn’t work, you can be confident the problem is in your firmware, not a dead board, a bad cable, or a misconfigured jumper. That certainty is worth the 20 minutes this process takes.

You’re ready for real firmware: GPIO configuration, peripheral drivers, interrupt handlers, application logic. The next steps are learning how GPIO works beyond toggling an LED and going deeper into UART for structured serial communication. The board is proven. The mystery is eliminated. Go write code.

Hubble Network connects your embedded devices directly to satellite from a standard Bluetooth chip—no extra hardware, no ground infrastructure. See how it works →