Embedded Systems & Product Development Consultancy · London, UK

Hardware/software integration and board bring-up

Integration problems sit between teams, so we work on both sides of the line: schematic and scope, driver and debugger. We bring new boards to life, write the drivers that connect firmware to hardware and stay with the system until it behaves the way it was designed to.

Discuss your firmware See case studies

When the fault is always on the other side

The hardware passes its checks and the firmware passes its tests, yet the product still doesn’t work, and each team has evidence that the problem is on the other side.

A new board arrives and nobody can get the processor to boot or the debugger to connect.
A peripheral that works on its own fails once the radio, display and motors run at the same time.
Resets, lock-ups or corrupted data that come and go with temperature, supply voltage or load.
Hardware and firmware teams in different offices, time zones or companies, each waiting for the other.
Prototypes patched with wires and resistor changes that nobody has written down.

These problems are rarely one team’s fault. They need someone who reads the schematic and the code together and measures what the board is actually doing.

See how we work

What we do

From the first power-up of a new board to a system that runs reliably as a whole.

First-board bring-up

Power rails, clocks, reset and debug access checked step by step, then the processor, memory and every peripheral brought up in a planned order.

Drivers and board support

Drivers for sensors, IMUs, NFC, displays, motors, radios and memory over SPI, I²C, UART, USB, ADC, PWM and DMA.

Hardware test firmware

Small, focused programs that exercise each part of the board, so a hardware fault shows up as a clear result rather than a guess.

Feedback for the next revision

Measured findings your hardware team can act on, with scope captures and test results as evidence.

How we bring up a board

A planned bring-up finds faults one at a time, in the order they matter, instead of all at once on the day of the demo.

Read before power. Schematic, layout and datasheets reviewed against the firmware plan before the first board is switched on.
Power up in stages. A current-limited supply, then rails and clocks measured one by one, and debug access confirmed before any application firmware is loaded.
One interface at a time. Each peripheral brought up with a small test, its signals checked on the oscilloscope or logic analyser against the datasheet.
Then the whole system. Everything running together under realistic load, temperature and supply conditions, because that is where integration faults show themselves.
A bring-up report. What works, what was changed on the board, what the next revision needs, and the test firmware to repeat every check on later builds.

Tools and platforms

Lab: oscilloscopes, logic analysers, battery analyser, current-limited bench supplies, BLE diagnostic tools

Debug: Segger J-Link, SWD and JTAG, IAR, Keil, MCUXpresso, MPLAB X

Processors: STM32, NXP i.MX and i.MX RT, Nordic nRF52, ESP32, Silicon Labs EFR32, Microchip PIC32 and SAM

Test automation: Python, C#, YAML-driven test jigs, CI pipelines

Integration in shipped products

Client names stay private. The engineering doesn’t.

A low-power wearable medical device, from concept to pre-production

nRF52840 hardware and Zephyr firmware with BLE telemetry, secure provisioning and OTA updates, taken through bring-up, power optimisation and production preparation.

Read the case study

An ATM security device, from schematic to 40,000 units in 24/7 service

Supply noise from older ATM power units traced and designed out, then more than 40,000 devices supported in round-the-clock field service.

Read the case study

More integration work

Test software that helped a hardware team correct a marine radio baseband design, an i.MX 6 carrier board with a custom Yocto build, a USB-controlled three-axis gimbal test platform and more.

View case studies

Frequently asked hardware questions

Can you bring up a board someone else designed?

Yes, and much of our bring-up work is on hardware we didn’t design. We start from the schematic, layout files and datasheets, and come back with clear findings for the designer.

Do you need the boards in your lab?

For the first bring-up, ideally yes. It goes faster with our own instruments on the board, so send us a few units. Later stages can run remotely or on site with your team.

Our hardware and firmware teams blame each other. Can you help?

Yes. This is where an engineer who works on both sides is most useful. We reproduce the fault, measure it, show the evidence and fix it on whichever side it belongs.

How long does bring-up take?

It depends on how much of the board is new. A microcontroller board built from familiar parts can often be running within days; a custom Linux board or a first RF design takes longer. After reviewing the design, we give you a plan with milestones.

Can you write drivers for a part we’ve just chosen?

Yes. We work from the datasheet and application notes, verify the driver on the scope or logic analyser and hand it over with a test.

1. What do we keep at the end?

The bring-up report, the hardware test firmware and, where it helps, a test jig, so your team can repeat every check on each new build.

Have a new board on the bench, or a system that won’t behave?

Tell us what the board is and what it is, or isn’t, doing.

Share your project with us, and we’ll get back to you within one business day.

Talk to an engineer