What is hardware testing in embedded systems?

Checking that a board's power, clocks, buses and peripherals work, and that they work with its firmware. It runs from first power-up through bring-up to regression tests on every new revision.

What is the first test to run on a new PCB?

Before applying power, check the rails for shorts to ground. Then power up current-limited and measure each rail before loading any firmware.

Can hardware testing be automated?

Partly. Bench measurements need a rig or a person; wiring, bus, power-order and firmware-behaviour checks can run automatically against a simulated board in CI.

What can't be tested before a prototype exists?

Anything that depends on the physical build: analog accuracy, noise, thermal behaviour, RF performance, assembly defects and compliance. Plan the first prototype around those.

Hardware testing for embedded boards

Adam Szefer · Co-founder & CTOOctober 22, 2026

Prev. Bloomberg · Gyfted. Systems and simulation infrastructure — the engine that runs your firmware against the circuit.

For an embedded team, hardware testing means proving that a new board works with the firmware it was designed for. This is how to test hardware on a fresh PCB, which checks to run first, and how much of it can start before the boards arrive.

How to test hardware on a new PCB

Start before power: inspect the assembly, check for shorts between rails and ground, confirm part orientation. Then power up from a current-limited supply and measure every rail. Next, load the simplest firmware that toggles a pin and prints over a UART, and bring up one peripheral at a time. Each step narrows where a fault can be, so a failure stays cheap to find.

A bring-up checklist: power, clocks, buses, peripherals

Power: each rail at the right voltage, in the right order, within its current budget. Clocks: the crystal or oscillator starts and the MCU runs at the frequency the firmware expects. Buses: every I²C device answers at its address, SPI chip selects reach the right parts, UART levels and baud rates match. Peripherals: each sensor, driver and radio does what its datasheet says when the firmware asks. Keep the results; they become the regression suite.

Testing hardware before the first prototype

Much of that checklist depends only on the schematic and the firmware, not on copper: which pin drives which enable, which address each chip uses, whether the rail powering a sensor is on when the firmware talks to it. A board simulation built from the netlist runs those checks while the design is still open, so the first prototype is spent on what only a physical board can show: analog accuracy, noise, thermal, RF.

Automating hardware tests in CI

Hardware tests are hard to automate because boards are scarce and rigs need care. Split them. Checks that need physics stay on a bench or a HIL rig; checks about wiring, buses, power order and firmware behaviour move to a simulated board that runs headless on every commit. When a firmware change breaks a bus or a power sequence, CI fails before anyone flashes a board.

FAQ

What is hardware testing in embedded systems?: Checking that a board's power, clocks, buses and peripherals work, and that they work with its firmware. It runs from first power-up through bring-up to regression tests on every new revision.
What is the first test to run on a new PCB?: Before applying power, check the rails for shorts to ground. Then power up current-limited and measure each rail before loading any firmware.
Can hardware testing be automated?: Partly. Bench measurements need a rig or a person; wiring, bus, power-order and firmware-behaviour checks can run automatically against a simulated board in CI.
What can't be tested before a prototype exists?: Anything that depends on the physical build: analog accuracy, noise, thermal behaviour, RF performance, assembly defects and compliance. Plan the first prototype around those.

HardLabs

Send us your design. We'll send you a simulator.

We build a board simulator from your netlist, schematic, and BOM, run your real firmware against it, and fail CI when pinmux, buses, or timing contracts break.

A working simulator of your board, built from netlist, schematic, and BOM.
Peripheral models attached so your firmware can talk to the board.
A setup that runs your real firmware binary — no rewrite required.

Pilot details · App

Bring-up before the prototype
Simulate board bring-up before the first prototype: power-on assumptions, bus enumeration, and firmware init against your netlist.
Simulate the PCB before fab
Simulate your PCB before manufacturing: run real firmware against netlist-derived buses and catch pinmux, address, and timing bugs while the schematic can still change.
Firmware testing guide
Embedded firmware testing explained: unit tests to hardware-in-the-loop, the best tools, and how to test firmware before the board exists.
Avoid integration respins
Avoid PCB respins caused by pinmux, bus, and timing mistakes — catch HW/FW integration bugs in simulation weeks before the first articles.

HardLabsAll topics