Shipping Matter
Factory Flashing at Scale: Tooling and Throughput
Abu
5 min read
Flashing 100,000 devices shares nothing with flashing a dev board over USB - we’ve done both. Production flashing is about zero-defect output at a rate your CM can sustain, not speed. The tools, fixtures, and verification are entirely different. Get it wrong and you ship devices with bit flips, corrupted firmware, or missing factory data.
Tooling
Three things you probably don’t have yet:
Gang programmer
A single-port J-Link isn’t the answer. You need a multi-site programmer that flashes several devices in parallel:
| Programmer | Targets | Best for |
|---|---|---|
| SEGGER Flasher ATE2 | 8-10 parallel (scales to 24) | High-volume multi-SoC |
| PEmicro Cyclone MultiChannel FX | 4-16 parallel | Mid-volume NXP/Freescale |
Nordic nRF Command Line Tools
(nrfjprog / nrfutil) |
Queued | BLE SoC production |
| SEGGER J-Link + multi-target | 2-4 | Low-mid volume |
Naming trap: the SEGGER Flasher PRO is single-target - the 8-channel gang programmer is the Flasher ATE2. Same for PEmicro: a Cyclone FX is single-channel; parallelism comes from the Cyclone MultiChannel FX or from Cyclone Control Suite coordinating several Cyclones. Buying “a gang programmer” by the wrong model name is the classic way to under-provision a line.
Programming jig
A jig is more than a pogo-pin bed. It has to guarantee alignment, control insertion force, and give the operator a pass/fail light. Requirements:
- Gold-plated pogo pins rated for at least 10,000 cycles (QA Technology, Everett Charles)
- Alignment pins matching your PCB’s tooling holes
- Insertion force control to prevent pad damage
- Pass/fail LED driven by the flashing script’s exit code
Budget 4-6 weeks for mechanical design and fabrication. This is not the thing to outsource in week one of a production ramp.
Post-flash verification firmware
Your production image needs a self-test mode that runs right after programming and reports:
- Checksum - SHA-256 hash of the application partition, checked against the signed manifest
- MAC address - confirms BLE/Wi-Fi identity is correct
- Factory data validity - DAC, CD, and PAI injection status
Operator flips a switch, sees green, moves to the next unit. Red means stop and investigate. Without this you’re shipping devices that “probably” have valid firmware.
Throughput math
| Variable | Value |
|---|---|
| Flash + verify time per device | 20 seconds |
| Units per hour per station | 180 |
| Stations (typical) | 3 |
| Units per hour (line total) | 540 |
| 100k-unit run at 8-hour shifts | 23 production days |
| With yield loss, rework, breaks | ~35 production days |
Your numbers will differ by part and programmer. The point isn’t the exact figures - it’s the gap between raw throughput and real production days. Plan for the rework, the yield loss, and the breaks, or your CM’s schedule estimate surprises you two weeks before the purchase order ships.
The “flash and pray” anti-pattern
The most expensive mistake: flashing with no cryptographic integrity check, shipping, then discovering in the field that a share of units have bit flips in the application partition. You won’t see it at the factory; you’ll see it in returns.
Your firmware image must carry a signed manifest with a SHA-256 hash, and the production tester validates that hash before the unit leaves the programming station.
| Vendor | Secure boot | Tool |
|---|---|---|
| Nordic | nRF Secure Immutable Bootloader | nrfjprog (being superseded by nrfutil) |
| Espressif | Secure Boot V2 (RSA-PSS or ECDSA) | esptool.py + espsecure sign-data --version 2 |
| Silicon Labs | Secure Boot ECDSA (P-256/SHA-256) | Simplicity Commander |
This is not optional at scale.
Firmware version management
Maintain a firmware version manifest that maps:
- Firmware image version -> VID, PID, hardware revision, production date range
- Flash layout -> partition table, factory data offset, secure storage region
- DAC batch range -> which serial numbers map to which DAC batch and PAI certificate
One document, kept current. If a DAC batch is compromised or revoked, you need to know exactly which units are affected.
FAQ
How many devices can I flash in parallel?
Depends on your programmer. SEGGER’s Flasher ATE2 handles 8-10 simultaneous targets (scalable to 24 with USB hubs); the single-target Flasher PRO does not scale that way. PEmicro’s Cyclone MultiChannel FX handles 4-16 channels. Nordic’s production tooling queues devices sequentially. For 100k-unit runs, 3 parallel stations at 180 units/hour each gives you ~540 units/hour line throughput.
What happens if I flash firmware without a signed manifest?
At scale, a nonzero share of units will show bit flips in the application partition during or after flashing. The units commission fine and then fail intermittently in the field - dropped connections, failed OTA updates, crashes. A signed manifest with SHA-256 validation catches the bit flips at the programming station instead of in the customer’s home.
How long does a production jig take to build?
4-6 weeks for mechanical design, fabrication, and pin alignment validation. Start jig design before firmware freeze. If you outsource jig fabrication in week 1 of production ramp, you will miss your CM’s schedule.
What is the difference between prototype flashing and production flashing?
Prototype flashing uses a USB-to-serial adapter, a single J-Link, and manual operator steps. Production flashing uses gang programmers, pogo-pin jigs, signed manifest verification, pass/fail indicators, and serial number tracking - all integrated into the CM’s line management system. The gap is process engineering, not firmware.
Part of the Shipping Matter series. See also: DAC Provisioning Pipeline , End-of-Line Testing .