Reverse-engineering pinouts from an undocumented PCB

A surprising amount of repair work ends up being on hardware where no public schematic exists. Vintage industrial controllers from companies that folded in the nineties. Custom one-off boards somebody had made for a now-defunct product line. Modern consumer devices where the manufacturer treats the schematic as a trade secret and the service docs as a hostage. If you only ever work on hardware with a published service manual, you'll turn away half the interesting jobs.

The good news is that a PCB is a finite object. Every track goes somewhere. Every pin has a function. With nothing more than a multimeter on continuity, a microscope or loupe, and a few hours of patience, you can rebuild enough of the schematic to do useful work. This article is the workflow we actually use on the bench when something arrives with no documentation.

For a recent example: most of our firmware-side work on the Creality K2 — the patches, the SWD pad locations, the toolhead board signal map — started exactly like this. Creality publish almost nothing useful. The board on the printer was treated as a black box until we sat down and methodically traced it.

Step 1 — Identify every IC

Get a microscope or a decent loupe and read every chip label on the board. Don't trust your eyes from arm's length. Tiny SMD parts often have laser-etched markings that are invisible under room lighting but pop under raking light from a desk lamp held at an angle. SOT-23 three-pin parts in particular love to hide their identity.

Write each part number down. Then cross-reference every one of them — Octopart is usually the fastest, followed by Mouser, then the manufacturer's own site. Even genuinely obscure parts almost always have at least an application note floating around somewhere. Chinese-market parts may need a search on LCSC. House-numbered parts (custom markings) are the only ones that genuinely defeat you, and even those you can often identify by package and surrounding circuit.

While you're doing this, classify each IC. There will be one or two "main" parts — the microcontroller, the ASIC, the main switching regulator — and a constellation of supporting parts: linear regulators, level shifters, EEPROMs, op-amps, MOSFETs, protection diodes. Knowing which is which lets you ignore most of the board most of the time.

Step 2 — Map the power rails

Find the DC input. Trace it through any reverse-polarity protection, rectification, or filtering, until you reach the regulators. Regulators are usually named in a friendly way — a 7805 is a 5 V linear, an AMS1117-3.3 is a 3.3 V linear, an MP2307 is a buck. The datasheet tells you which pin is the output.

Now, for every IC on the board, look up its datasheet and identify its power and ground pins. Put the multimeter on continuity and beep from each regulator output to each IC power pin. This tells you which IC runs on which rail. Note the voltages on your sketch — 5 V, 3.3 V, 1.8 V — because when you come back with a scope later, that's the difference between reading a clean logic signal and concluding the board is dead.

Don't skip this step even if you're impatient. Knowing the rails first means you won't probe a 1.8 V GPIO expecting 3.3 V and waste an hour wondering why nothing makes sense.

Step 3 — Map the signal nets

This is the slow bit. A net is just "anything that is electrically connected together". Most boards have somewhere between 50 and 500 distinct nets. That sounds like a lot, but it's finite, and you only need to identify the ones you care about.

Put the meter on continuity and beep from every IC pin to every other IC pin, and to every connector pin. Build a spreadsheet, or use a paper grid — one row per pin, columns for "connects to". Trace methodically. Don't trust your memory after the third chip; you will get pins mixed up, and you'll waste a day chasing a fault that doesn't exist.

Visual tracing of tracks on the silkscreen-side of the board alone will fail you on anything four-layer or denser. Vias drop signals onto inner layers where you can't see them. The continuity beep is the source of truth — if the meter beeps, those two points are connected, even if you can see no copper between them.

Step 4 — Identify the buses

Once you have the net list, the buses jump out. SPI and I2C and UART all have characteristic signatures. I2C is two wires (SDA, SCL) with pull-up resistors to a rail — those pull-ups are dead obvious on a continuity test. SPI is three or four wires (MOSI, MISO, SCK, optional CS) running as a bundle between the microcontroller and one or more peripherals. UART is two wires (TX, RX) usually heading to a connector or a USB-to-serial bridge.

JTAG and SWD debug headers are worth identifying even if you don't intend to use them today. They're often unpopulated pads near the main IC — a row of 4 to 10 tiny vias with no obvious purpose. Future-you, trying to recover a bricked microcontroller, will thank present-you for noting them down.

GPIO lines and ADC inputs typically route straight from the microcontroller to a connector or a sensor, with maybe a series resistor in line. They're the easiest signals to identify and usually the ones a repair turns on.

Step 5 — Verify with the scope

Now power the board up. Carefully. With a current-limited bench supply if you're unsure.

Probe the signals you identified. Confirm direction (which pins drive, which receive) and protocol. An I2C bus shows the characteristic stair-stepped clock and data. SPI shows a clean burst at whatever frequency the MCU was configured for. UART shows roughly square pulses at standard baud-rate widths. Audio and analog lines show waveforms at expected frequencies.

Anything that doesn't match your map means your map is wrong. Go back, re-beep the suspect net, find the mistake. It's almost always a misread on the continuity step.

A worked example: the Creality K2

When we started working on the K2, the toolhead board had no public schematic and Creality were not forthcoming. We did exactly this workflow over a weekend — identified the STM32 main MCU, the stepper drivers, the thermistor amplifier, mapped the I2C bus running to the accelerometer, and found the unpopulated SWD pads next to the MCU. The resulting local schematic is what informed the patches we later contributed back toward mainline Klipper. None of that would have been possible without sitting down with the meter first.

When to stop

You almost never need 100% of the board mapped. 60-80% is usually enough to do a useful repair — enough to find a fault, identify the failed part, and confirm the surrounding circuit is intact. Don't burn three weekends mapping the rest of the board if all you needed was to trace one stuck output.

For workshops: this kind of work takes years to be quick at, and the customer is paying our fair £80/h bench rate while you do it. We don't bill for "learning a board" in the abstract — that's our overhead. But we absolutely do bill for the time it takes to find the actual fault on the actual board in front of us, and a chunk of that time is this methodology.

---

If you've got an obscure board with no documentation and a fault you can't trace, send it in. We do this kind of work routinely, and we'd rather be doing it than not.

See also

• Reading a schematic for the first time: a primer
• PSU faults: capacitor vs MOSFET failure