A firmware and PCB copy bundle means one project handles two jobs: rebuilding the manufacturing files for the board from a physical sample, and reading the code out of the microcontroller so the rebuilt board actually functions. You get Gerbers, a BOM, and a programmable binary that runs on the same part. Ordering them separately is where most people lose a month, because the two halves have to agree on one thing — the exact chip on the board.
Why the bundle exists at all
A copied board with an empty MCU is a paperweight. That sounds obvious, but it’s a surprisingly common outcome when a maintenance team orders board duplication from one vendor and then starts shopping for code readout afterward. By then the original sample has been depaneled, desoldered, or sometimes milled for layer separation, and the one chip holding the firmware is gone.
The typical caller is a maintenance engineer or a plant owner with a machine still in service and no source files. The OEM is gone, or the board is out of production, or the guy who wrote the code retired in 2011. The board still works — that’s the point. You want another one, or twenty more, and you want them to behave identically.
Running board duplication and firmware extraction as a single bundle protects the sample. The chip comes off first, or gets read in-circuit first, before anything destructive happens to the substrate.
The order of work, and why the order matters
Sequence is the whole trick here. Here is how a bundled job actually runs on the bench:
- Intake and photography. Both sides get shot at high resolution before a single component moves. Silkscreen, reference designators, connector pinouts, any hand-rework or bodge wires. Once parts come off, the silkscreen under them is the only record of what belonged there.
- Chip identification and firmware feasibility. The engineer reads the top marking on the MCU under a microscope — full part number, package, revision, date code. This is the single most important minute of the project. Whether the code can be read, and at what cost, is decided by that marking.
- Code readout attempt. Done before layer work, either in-circuit through the debug header if one exists, or after careful removal of the MCU. If the chip has to come off, it’s socketed or wired to a fixture, never soldered into a scrap board.
- Component identification and BOM build. Passives are measured or read from markings; ICs are cataloged by marking and package. Anything unreadable gets flagged rather than guessed.
- Layer work and copper recovery. Outer layers are scanned; inner layers on a multilayer board are exposed and imaged one at a time. Drill positions, via types, and stackup are recorded as they’re found.
- File generation and cross-check. Gerbers, drill file, pick-and-place, BOM. Netlist is verified against continuity measurements taken on the original board, not just against the scan.
- Prototype build and functional check. New bare boards, assembled, MCU programmed with the recovered binary, powered up, and compared against the original sample’s behavior.
That last step is the only real proof the bundle worked. Files that look right and code that reads clean still have to run together. A prototype run is where a mislabeled pull-up or a swapped crystal shows up, and it’s much cheaper to find it there than in your machine.
Reading the chip before the board comes apart
If the MCU has to be decapsulated or otherwise treated invasively, that chip is not going back on the board. That’s fine — you’ll be programming fresh parts anyway — but it means the original sample loses its brain early. Which is another reason the board-level work should be planned around the firmware step, not the reverse.
What determines whether the firmware half is feasible
Board duplication is nearly always doable. Given a physical sample and enough time, copper is copper. The firmware half is the variable, and it depends almost entirely on the part number and how the original developer configured its protection.
Rough grouping, in the order we usually see them:
| Part family | Protection mechanism | General difficulty |
|---|---|---|
| 8051 derivatives, older AVR, small PIC | Lock bits / security fuses | Often straightforward; long track record on these parts |
| STM8, STM32 at RDP Level 1 | Read-out protection, level 1 | Commonly workable |
| STM32 at RDP Level 2 | Debug permanently disabled, option bytes locked | Hard. Sometimes not feasible at all — depends on die revision |
| MSP430 | JTAG fuse, BSL password | Depends heavily on which is set and how |
| Serial EEPROM and external flash (24Cxx, 25xx) | Usually little or none | Generally the easy part of the job |
| Modern parts with secure boot or on-die encrypted flash | Hardware crypto, key in fuses | Frequently not feasible; we say so up front |
We don’t quote a success rate, and you should be skeptical of anyone who does. What we do is look at the marking and tell you which of three buckets your part falls into: we’ve done this exact device many times, we’ve done close relatives and think it’s likely, or we don’t believe it’s practical and here are your alternatives.
When the firmware can’t be recovered
This happens, and it isn’t the end of the project. Two paths usually remain. First, the board files still have value on their own — you can rebuild hardware and write new firmware against a recovered schematic, which is far cheaper than a clean-sheet redesign. Second, if a working unit exists, functional behavior can be documented well enough to specify replacement code. Neither is as fast as a clean readout, but both beat scrapping the machine.
What to send us, and what comes back
Getting a real answer instead of a “contact us for pricing” reply comes down to five things. Send these and you’ll usually get feasibility, lead time, and price in one reply.
- Clear photos of both sides, whole board in frame, laid on a dark non-reflective background. Even lighting, no flash glare across the silkscreen. Shoot straight down, not at an angle.
- Board dimensions — length, width, and thickness in millimeters. Plus layer count if you know it.
- A close-up of the MCU marking, sharp enough to read every character including the revision code and date code. This one photo drives the entire firmware quote.
- One line on which deliverables you need. “Gerbers plus BOM plus a programmed sample” is enough. “Everything” is not, because it costs you money you may not need to spend.
- Quantity and intent — one spare, a shelf of spares, or a production run. It changes how we build the files.
What comes back from us: a feasibility statement split into board and firmware, a realistic lead time, a price, and a note on anything we can’t promise. If we think your part sits in the hard bucket, you’ll hear that before you ship anything. Details of the file set are on our page covering what you actually receive at handover.
What drives the price and the schedule
There’s no flat rate, because the two halves of the bundle scale on different variables. Board cost tracks layer count, board size, component count, and whether there are BGAs or blind and buried vias to resolve. Firmware cost tracks the specific part number and its protection state — a common 8-bit part with lock bits set is a different conversation from a modern ARM device with debug fused off.
Schedule works the same way. A two-layer control board with through-hole parts and a well-understood 8051 moves quickly. A six- or eight-layer board with fine-pitch BGAs plus an MCU that needs invasive work takes meaningfully longer, because the inner layers have to be imaged separately and the firmware path may involve more than one attempt. We break the drivers down further under what reverse engineering actually costs and give realistic ranges on how long jobs take.
One practical note: the firmware step is usually the schedule risk, not the board. Copper work is predictable. Code readout on an unfamiliar part is not.
Legitimate use, and the paperwork
The bundle exists for people maintaining equipment they own or support — recovering firmware whose source and hex are gone, keeping out-of-production machinery running, migrating a design off an obsolete MCU, and failure analysis. Those are the jobs that come through our door. You’re responsible for holding the rights to the design and for complying with applicable IP law in your jurisdiction; we work under NDA on every project and don’t retain your files or binaries after handover.
If you’re not sure whether your situation qualifies, describe it in your first message. We’d rather decline early than halfway through.
FAQ
Can you copy the board if the MCU firmware turns out to be unreadable?
Yes. The board-level work is independent — Gerbers, drill data, BOM, and netlist all come from the physical sample and don’t depend on the code. You’d end up with manufacturable hardware and a blank MCU. Many customers take that route deliberately, then write new firmware against the recovered schematic. It’s slower than a clean readout but much cheaper than redesigning from scratch.
Do I have to send the original board, or are photos enough?
Photos are enough for a quote. They are not enough for the work. Inner-layer copper, exact drill positions, and stackup can only be recovered from the physical sample, and firmware readout obviously requires the actual chip. Send two identical units if you have them — one gets consumed, one stays intact as the reference for functional comparison.
Will the recovered firmware run on a newer version of the same chip?
Usually, within the same family and flash size, but it needs verifying rather than assuming. Peripheral register maps and option-byte layouts shift between revisions, and errata workarounds baked into old code sometimes break on newer silicon. If your original part is obsolete, tell us at quote time so we can plan a migration check into the prototype build
Working on a board like this?
Send the chip marking or two photos. You get feasibility, lead time and price within 24 hours, and the check costs nothing.
Get a free quote