Do you need our firmware source code?

No. We run the binary you already build (ELF or bin). If you'd rather send source and a toolchain, that works too. The firmware is not changed for the simulation.

Which MCUs can you test firmware on?

Arm Cortex-M families, including STM32 (F4, G4 and H7), Nordic nRF53 and nRF54L, Ambiq Apollo3 and Microchip SAM V71. Coverage grows with every pilot, so ask about yours.

Which design files do you need?

A netlist, the schematic PDF and the BOM. KiCad and Cadence (OrCAD or Allegro) netlists load directly. From other design tools, send the export you have and we'll work from it.

What if a part on our board has no simulation model?

We tell you up front. Parts without a model are listed, and can be stubbed so the rest of the board runs or modelled during the pilot. A missing model is never reported as a passing test.

Can you automate our firmware regression testing?

Yes. The checks from the engagement are saved as scenarios that run headless against the simulated board, so your CI can run them on every commit. Your team can add new scenarios as the firmware grows.

Does this replace testing on real hardware?

No. It moves wiring, bus, power-order and firmware bugs to before the first prototype. Final electrical validation, RF and compliance still need the physical board.

Is our design kept confidential?

Yes. Work is under NDA, your netlists and firmware stay yours, and we don't train on customer designs. Self-hosted and air-gapped deployment is available.

Firmware testing services, run on a simulation of your board

Agnieszka Szefer · Co-founder & CEOOctober 22, 2026

Prev. Stitch Fix · Amazon · Bain Capital Ventures. Built ML systems in production at scale; runs how we turn datasheets into models.

Outsourced firmware testing usually means shipping prototypes to a lab and waiting for a report. We work the other way round: you send the design files and the firmware you already build, we build a simulator of that exact board, and your unchanged binary runs on it, before the first prototype exists and again on every commit after.

What our firmware testing covers

The places where firmware meets the board: boot and clock setup, pin assignments, GPIO and interrupts, I²C, SPI and UART traffic with the parts actually on each bus, timers and DMA, and power: rails, sequencing, battery droop and injected faults. A board with a Bluetooth stack gets a virtual phone to scan, pair and read GATT services; a USB device enumerates on a virtual computer; a cellular modem registers on a simulated network. Every signal is recorded, so each finding comes with the edge, bus transaction or voltage that shows it.

How a firmware testing engagement works

You send a netlist, schematic PDF and BOM for one board or subsystem, plus the firmware build you use today. We read the design, tell you which parts already have simulation models and which don't, and build the board. Your firmware runs on it unchanged: no mocks, no special build. We run the tests we agreed on, plus checks generated from the design itself, and walk you through what failed and why.

What you get back

A findings report that separates firmware bugs, hardware bugs and design-file mismatches, each with the evidence behind it. The board simulator itself, which your team can run, debug and drive from the browser, the command line or an AI coding agent. And the test scenarios, so the same checks run headless in your CI on every firmware commit. You keep what we build.

What it has found on real boards

From design-partner boards, names withheld: a motor driver whose data-out pin never reached the MCU, so register readback could not work on that revision; a charger whose hold the firmware restored only on its next 2-second check; a Makefile comment that silently compiled out all logging; a netlist and BOM that disagreed on the flash size. None of these needed a prototype to find.

Automated embedded firmware regression testing

Every finding becomes a scenario: a saved sequence of inputs and checks that runs against the simulated board without anyone watching. Wire the scenarios into CI and each firmware commit is regression-tested against the board it ships on: buses still enumerate, rails still come up in order, a fixed bug stays fixed. They run from the HardLabs command line, so they fit GitHub Actions, GitLab CI or any runner that can call a CLI.

Firmware testing services compared to a test lab or a HIL rig

A test lab or a hardware-in-the-loop rig tests the physical board: RF, analog accuracy, thermal, compliance. It needs prototypes, fixtures and bench time, and each run is slow to repeat. A simulated board needs none of that and repeats in seconds, but it is only as good as its models, so we state where each model stops. Most teams use both: simulation to clear integration bugs early, the bench for physics.

How a pilot starts

A pilot covers one board or subsystem. Send the design files with a short note on what worries you (a bus, a power-up sequence, a driver) and we scope from there. Work is under NDA, we don't train on customer designs, and on-prem or air-gapped setups are available for export-controlled teams.

FAQ

Do you need our firmware source code?: No. We run the binary you already build (ELF or bin). If you'd rather send source and a toolchain, that works too. The firmware is not changed for the simulation.
Which MCUs can you test firmware on?: Arm Cortex-M families, including STM32 (F4, G4 and H7), Nordic nRF53 and nRF54L, Ambiq Apollo3 and Microchip SAM V71. Coverage grows with every pilot, so ask about yours.
Which design files do you need?: A netlist, the schematic PDF and the BOM. KiCad and Cadence (OrCAD or Allegro) netlists load directly. From other design tools, send the export you have and we'll work from it.
What if a part on our board has no simulation model?: We tell you up front. Parts without a model are listed, and can be stubbed so the rest of the board runs or modelled during the pilot. A missing model is never reported as a passing test.
Can you automate our firmware regression testing?: Yes. The checks from the engagement are saved as scenarios that run headless against the simulated board, so your CI can run them on every commit. Your team can add new scenarios as the firmware grows.
Does this replace testing on real hardware?: No. It moves wiring, bus, power-order and firmware bugs to before the first prototype. Final electrical validation, RF and compliance still need the physical board.
Is our design kept confidential?: Yes. Work is under NDA, your netlists and firmware stay yours, and we don't train on customer designs. Self-hosted and air-gapped deployment is available.

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

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.
What is HIL testing?
HIL testing explained: how a hardware-in-the-loop test system works, HIL vs SIL testing, HIL in automotive, and testing before the hardware exists.
HIL alternative before hardware
Need HIL-class coverage before PCBs exist? HardLabs runs unmodified firmware against a netlist-derived board model — a software HIL path for schematic freeze.

HardLabsAll topics