What test points and programming pads a board needs

The prototype works. You flashed it with a clip and a wire, probed three rails with a meter, and it booted. Then the first batch comes back from assembly and nobody can load firmware without soldering to a fine-pitch pin. Production test needs access that the layout never provided, and the fix is a new board revision.

None of this is hard to prevent. It is a short list of decisions made while the schematic is still open.

Start with how firmware gets onto the chip

Every board needs one defined way to load the first image, and it should work on a bare, unprogrammed chip. Pick it before you place connectors.

• ARM Cortex-M parts (STM32, Nordic nRF52, Microchip SAM) use SWD: SWDIO, SWCLK, ground, a voltage reference and, usually, reset. That is a handful of signals.
• ESP32 parts load through a ROM serial bootloader. Per the esptool boot mode documentation, GPIO0 held low at reset selects it. Development boards use the USB-serial chip’s DTR and RTS lines to drive GPIO0 and EN automatically. If your product has no USB-serial chip, a fixture has to drive those two pins itself, so both need pads, along with the UART TX and RX.
• Parts with a native USB bootloader can be loaded over the product’s own USB connector. That is convenient, but check how the chip enters bootloader mode when the flash is blank or corrupt, and whether a fixture can force it.

Whatever you choose, the pads are for the line, not just for you. A bench engineer can hold a probe against a pin. A fixture needs a pad it can land on every time.

Pick a connector, or none

A 0.1-inch header is the easy answer, and it costs board area and a part on the bill of materials that the customer never sees. For a small product, there are three usual alternatives.

Bare pads for a spring-pin fixture. The pads cost nothing in parts. Programming then happens on a fixture, which pairs naturally with testing. The fixture needs registration features, which we cover in designing a pogo-pin test fixture that lasts.

A footprint-only cable connector. Tag-Connect’s TC2030 is a six-pin plug-of-nails cable that mates to a small pad pattern on the board, with no connector soldered on. Its product page lists ARM Cortex SWD among the supported interfaces. The cable is held by hand or a retaining clip, so it suits development and rework better than unattended production. Confirm the pinout of your target interface against the vendor’s documentation before committing the footprint.

A populated header, depopulated for production. Keep the pads and the routing, leave the part off. If you later need it for field service, it is a rework step instead of a respin. This only works if the stub does not disturb the signals, which is rarely a concern for SWD but can matter for fast buses.

Do not leave the decision for later. Pads placed after layout end up wherever there was room, which is how you get a programming port blocked by a tall capacitor.

Reset and the locked-chip case

Two failures show up in the first week of production, and both come from the reset line.

First, a debugger often cannot attach to a chip that is running code that puts the pins to other uses, sleeps deeply, or reconfigures the debug pins. The usual cure is to connect with reset asserted. OpenOCD’s reset configuration documentation describes a connect_assert_srst option for exactly this, and notes it helps when you cannot connect because of bad option bytes or illegal program execution. That only works if the debug connection can drive the target’s reset. If you left reset off the programming pads to save a pad, you have removed your recovery path. Bring reset out.

Check the reset circuit, too. A supervisor or a large capacitor on reset can make the line slow or contested. Verify that a debugger can pull it low and release it cleanly on a built board.

Second, read-out protection. Many MCUs ship with, or later get, a lock that blocks the debugger. On Nordic nRF52 devices the debug and trace documentation says access port protection blocks debugger access, is cleared by an ERASEALL command through CTRL-AP, and defaults differ by build code: some parts ship with protection off, later ones with it on. A programming procedure written for one silicon revision can fail on the next. Your fixture software should read the protection status, erase if needed, and confirm the result, instead of assuming. If you are also locking production units on purpose, the order of operations matters; see provisioning serial numbers and keys on the production line.

Test points for the checks that matter

Test points should be chosen by asking what a fixture must decide: is this board good enough to ship? Work backwards from the faults assembly can actually produce.

1. Every power rail. One pad per rail, plus a ground nearby. This is the first check and the cheapest, since a shorted or missing regulator shows up immediately.
2. Programming and debug signals, as above, including reset.
3. A console UART, or whatever interface the firmware uses to report a self-test result. This often replaces dozens of analog probes: the firmware tests its own sensors, radio and memory, and reports pass or fail over one serial link.
4. Signals the firmware cannot check on its own, such as an analog input driven by an external stimulus, an output that drives a relay, or a current-sense node.
5. Stimulus and load points where the fixture injects a signal or applies a load, such as a battery input.

For each pad, decide which side of the board the fixture touches. Put them all on one side if you can. A two-sided fixture is a larger, more costly mechanical build than a single-sided one.

In KiCad, the standard library has a TestPoint set with round, square and pin-header styles, and the schematic symbol keeps them in the netlist so they are not lost in a cleanup. Treat library pad sizes as a drawing convention, not a manufacturing rule. What probe size, pad size and keep-out you need depends on the probe you select and on the assembler’s requirements, so confirm those numbers with whoever will build the fixture and the boards before you finish layout.

Keep the access once the board is crowded

Test access is the first thing lost when a layout gets tight. A few habits protect it.

• Name the test nets in the schematic and give them reference designators, so they survive review.
• Keep tall parts and mounting hardware clear of the pads and of the fixture’s contact area.
• Do not put a test pad on a net that must stay quiet. A long stub on a clock or a high-impedance node is a bigger risk than the probe it serves. Check each analog and fast node before adding a pad.
• Provide fiducials or tooling holes the fixture can register on. Without them, alignment depends on the board edge alone.
• Re-check access on the final board file. Pads that existed in the first draft often disappear when parts move.

How we approach it

We treat programming and test access as part of the schematic, not an afterthought, and we design the fixture alongside the board when the product needs one. To get a useful review, send us the schematic, the board files, the MCU part number, and a short description of what “good” means for a finished unit.