Board bring-up

From your PCB to verdicts.

What it takes to get your board onto the Oracova bench: the documents, the hardware, and the bring-up. Two paths, depending on whether you already have working firmware.

STEP 1 Documents What the bench stands in for STEP 2 Hardware A DUT board from your documents, a base board sized to your power STEP 3 Bring-up An AI agent, with your confirmation RESULT Verdicts PASS or FAIL on the bench
STEP 1

The documents

First, collecting information. This is what the bench will stand in for. A DUT board PCB counts as a document too, if you already have one.

your actual PCB schematics datasheets pin assignments how the product works DUT board PCB, if you have one
STEP 2

The hardware

From your documents, a custom DUT board is designed for your microcontroller and goes onto the Oracova base board. You choose the base board by how much power your system needs. DUT designs are open source.

Oracova base board

The world, in real time

Plays your sensors and loads, protocol-exact, and runs the physics models in real time. The world responds like the product's world does. Comes in variants; you pick one by how much power it has to source and sink.

Analog front-end modules

Voltages and currents, handled

DAC and ADC modules come in different resolutions and speeds; you pick the ones your signals need. Unusual signal? A module can be built for it.

Custom DUT + debug probe

Your microcontroller's seat

Built for your part, every pin routed to the base board. Your code runs on your real silicon, not a substitute part.

flash · reset · inspect
The probe

The debug probe flashes, resets, and inspects the target while it runs.

Benches are cheap to replicate. One per PR, one per agent, as many as your team runs in parallel.

STEP 3

The bring-up

Now the world comes up. An AI agent does the work, with your confirmation along the way.

On either path, expect some questions about your hardware and its physics, or documentation that answers them. The agent asks, it does not guess.

How long bring-up takes depends on your board. We scope it, with a number, on the call.

If you have working firmware

01Read the source The AI learns the world your firmware expects: peripherals, protocols, what it drives and senses.
02Write the world It writes the I/O behavior and the physics models.
03Run and compare Your unmodified binary runs on the DUT, the debug probe watching internal state, behavior compared against the field.
04Iterate to golden Until your firmware runs on the bench the way it runs in the product. That recording is golden; the suite builds on it.

If you do not have working firmware yet

01Peripheral by peripheral The bench and the firmware grow together, interface by interface.
02Both sides together The firmware driver on the DUT and its counterpart in the world, brought up as a pair.
03Proven before the next Each peripheral passes on the bench before the next one is added.
04The suite is the record By the time the firmware is whole, the regression suite already exists. There was never an untested part.
The open-source marketplace
gyro · LCD · hall encoder · and more

The world rarely starts from zero. Common peripherals come as validated models from Oracova's open-source marketplace, already proven against real firmware on other benches. The AI builds what is unique to your product and pulls the rest. And what you build, you can contribute back.

Where the boundary sits
Emulated

Everything your MCU senses and drives

Digital buses connect directly; analog signals go through front-end modules built for your board.

GPIO · PWM · UART · I2C · SPI · CAN
Not emulated

Your power stage

High voltage and high current stay off the bench. Your firmware still sees the same signals it would see in the product.

Proven today

The closed loop runs on real silicon now

motor commutation · servo · pump · thermal · unmodified Betaflight

See a scored run from the bench

Want to walk through it on your board?

Bring your schematic to the call. 15 minutes, no deck.

Book 15 minutes