Firmware doesn't magically appear on the MCU when the board comes off the line. Somebody has to flash it, and how that happens at the factory affects your security, your traceability, and how many bricked units you eat. I've seen a 1,000-unit run where every board shipped with the engineer's debug build because nobody specified the production image. Don't be that team.
Three ways to get firmware onto the board
Pre-programmed MCUs. You order the chip pre-loaded by the distributor or a programming house, and the factory just places it. Clean for the assembly house, but you lose control of the image, updates are painful, and you're trusting a third party with your binary. Fine for stable, high-volume parts; risky early when firmware changes weekly.
In-circuit programming on the line. The board is flashed after assembly via a test fixture that contacts your programming pads. This is the default for most runs. You hand the factory one image (or a small toolchain), they flash and verify each unit. You keep version control; the factory keeps throughput.
JTAG/SWD jig. A bed-of-nails or pogo-pin fixture hits SWD/JTAG plus power. Same idea as in-circuit, but it also lets you run a quick functional test in the same station — flash, read back, blink an LED, check current draw, all in one pass. Cost a few hundred dollars to build the jig; it pays for itself by catching dead boards before they get cased.
Securing the image and keys
The factory should never hold your signing keys or be able to produce extra units off the books.
- Ship a signed, release-tagged binary, not your repo. Strip debug symbols.
- If you have secure boot, provision keys yourself or via a key injection step you audit, not by emailing a private key to a contract manufacturer.
- Enable read-out protection / flash lockdown (RDP on STM32, flash protection bits on others) as the last step so the programmed image can't be dumped off a shipped unit.
- Account for every flash: a unit count per image hash tells you if more boards were programmed than you ordered.
Serial numbers, MACs, and traceability
Every connected device needs a unique identity, and the factory is where it gets injected. Decide who owns the namespace:
- Pull serial numbers / MAC addresses from a block you allocate, written per-unit during flashing.
- Have the line log SN ↔ test result ↔ image hash ↔ date to a CSV. That file is gold when an RMA shows up six months later and you need to know which batch and which firmware it shipped with.
- Print the SN on a label or QR at the same station so the physical unit and the database agree.
A factory-programming spec you can hand over
Put this in writing before the run. One page:
- Image: exact filename, build hash, signing status, target memory map.
- Method: in-circuit via SWD on pads TP1-TP4 (or named jig), at this station in the flow.
- Verify: read-back compare against hash; functional check (what to observe, pass/fail thresholds).
- Identity: SN/MAC source and range, where written, label format.
- Security: enable RDP/lock as final step; keys provisioned by [your step].
- Logging: per-unit CSV with SN, hash, timestamp, test result — delivered with the shipment.
- Reject handling: what happens to units that fail verify (quarantine, not rework-and-ship).
This is exactly the kind of detail that decides whether a run goes smoothly, and it's worth having someone technical confirm the factory can actually execute it. If you don't have an engineer who can read a test fixture and walk the line, an engineering-led agent like China Sourcing Agents can audit the programming station and check the per-unit logs against your order count before the units leave Shenzhen.
Write the spec, demand the log file, and lock the flash last. Production programming is boring when it's specified and a disaster when it isn't.
Top comments (0)