The failure this article is about is not exotic. A customer sends revision C of a firmware image on a Monday, engineering releases it to the line, and on Wednesday someone notices that the file on the programming station is still revision B. By then four hundred boards have been programmed and boxed. Nothing in the process failed visibly: the operator programmed the image that was on the station, the station verified against it, and every check passed because every check was testing the wrong thing.
Recovering from that is not a matter of reflashing. The boards are in enclosures, some are in transit, and the identification of which serial numbers carry which revision depends on records that may or may not exist. This is why programming in a contract environment is a version-control problem first and a soldering problem second.
Offline, In-Circuit and System-Level Programming
There are three places a device can receive its image, and the choice is driven by the device, the volume and the test strategy rather than by preference.
| Method | Where it happens | Typical throughput | Coverage | Best for |
|---|---|---|---|---|
| Offline (socket programmer) | Before placement | 300-800 devices/hour per station | Full: blank check, program, verify, checksum | High volume, small packages, devices that cannot be reached in-circuit |
| In-circuit (ICT or dedicated fixture) | After reflow, on the assembled board | 40-150 boards/hour depending on fixture | Program, verify, read-back; limited by test access | Medium volume, boards already tested on a fixture |
| System-level (bootloader or debug port) | After assembly, via connector or pads | 20-60 boards/hour | Depends entirely on the loader and the customer's script | Complex products, field updates, large images |
| Panel-level in-circuit | On the panel before depanelisation | 60-200 panels/hour | Program and verify per device | Volume production with good test access |
The throughput numbers above are from our own stations and will move with image size, device family and fixture design. The important point is the ratio: offline programming is between four and twenty times faster per device than in-circuit, which is why high-volume programmes program before placement whenever the package and the moisture sensitivity level allow it.
Firmware Version Control at the Programme Level
Version control in a factory is not the same problem as version control in a software repository. The factory does not need branches; it needs a single authoritative artefact per build, an unambiguous link between that artefact and the purchase order, and a check that the artefact on the station matches the one the customer released.
- One master file per build, received through a controlled channel, stored with a checksum computed on receipt and re-verified before every station load
- A revision identifier that the device itself can report, so that a finished board can be interrogated and asked which image it holds, rather than relying on a label
- A station record linking serial number, date, station identity, file checksum and operator, retained for the traceability period the customer requires
- A written rule for what happens when a new revision arrives while a lot is in progress: does the lot finish on the old image, or is it cut over at a defined serial number
- The customer's written approval for every revision change, referenced to a document, not to an email thread
The fourth item is where most disputes originate. A customer sends revision D and assumes it applies immediately. The factory has two hundred boards in process on revision C. Either the lot is split with two revisions in the field, or the in-process boards are reworked, or the cut-over is deferred to the next lot. All three are legitimate; only one of them matches what the customer expected, and the only way to know which is to have agreed it in advance.
Verify Coverage: What Programmed and Verified Must Mean
Programmed and verified is a phrase that appears in every capability statement and means different things at different suppliers. In a controlled process it decomposes into five checkpoints, each of which produces a record.
- Blank check before programming, which catches a device that is not blank and prevents an overwrite of a part that may have been used
- Program with the released image, with the station configured to the correct option bytes and protection settings rather than to the station defaults
- Verify by reading back the full programmed region and comparing against the file, not by sampling a portion of it
- Checksum recorded per device, so that a board can later be shown to hold the exact image that was released
- Functional confirmation where the device supports it, such as a boot handshake or an identification read, which catches a device that verifies correctly but does not start
Rule of thumb: a programming step without a per-device checksum record is not verified, it is attempted. If the supplier cannot produce a checksum by serial number for a given lot, there is no evidence that the lot holds the released image.
The cost of the missing checkpoints is asymmetric. Doing them costs a fraction of a second per device. Not doing them, and discovering the problem after the boards are boxed, costs a rework cycle that includes disassembly, the programming operation, reassembly, retest and reshipping, plus the schedule loss. On a five thousand board lot, a single revision error is measured in weeks.
What Belongs in the Programming Order
A programming order that can be executed without ambiguity contains: the device part number and package, the file to be programmed with its checksum, any option byte or security settings that differ from factory default, the programming method and the test access assumed, the expected quantity with an allowance for programming yield, the instruction for handling devices that fail programming, and the retention period for the per-serial records. Everything else is arrangement.
Security: Protecting Your Hex File Inside Someone Else's Factory
Handing over a firmware image is handing over the most valuable artefact in the product. Three controls are worth insisting on. The file should be transferred through a channel that does not leave it in an email inbox, and it should be stored on a station that is not reachable from the general network. Access to the station should be limited to named personnel with a log. And the file should be deleted, with written confirmation, at the end of the programme.
Where the device supports it, read protection should be enabled as part of programming, configured per the customer's specification rather than left at the factory default. This has a real consequence that must be agreed in advance: a read-protected device usually cannot be re-programmed without a full erase, so the rework path changes. Buyers should decide whether protection is enabled before the first lot, not after the first failure. The wider contractual picture is covered in our IP protection in contract manufacturing guide.
Cost per Unit and Where the Break-Even Sits
Programming cost per board is driven by four inputs: devices per board, seconds per device on the chosen method, station hourly cost including the operator, and programming yield. For a single device board, offline programming at three hundred devices an hour on a station costing forty-five dollars an hour gives fifteen cents per board in machine time, plus the logistics of handling the parts twice. In-circuit programming on the same board at eighty boards an hour gives fifty-six cents, but eliminates the double handling and the risk of damage during the extra pass.
The break-even between the two methods sits, on typical small boards, somewhere between two hundred and eight hundred units in a lot. Below that the fixture cost for in-circuit programming is not recoverable and offline wins. Above it, in-circuit programming usually wins on total cost because the handling and yield losses of the offline route grow faster than the machine-time saving. Panels and high device counts per board shift the crossover toward in-circuit, because the fixture is amortised over many more devices.
Choosing Between Panel-Level and Tray-Level
Panel-level programming happens before depanelisation, on the full panel with test access designed into the frame. It is faster per device because the panel moves once, and it is the default for volume production where the device can be reached. Tray-level, or offline before placement, is the choice for devices in packages that cannot be probed reliably in-circuit, for parts with a tight moisture sensitivity level that must be programmed and then reflowed in a controlled window, and for boards where test access conflicts with an RF or high-speed layout that cannot be compromised.
The decision belongs in the design phase rather than the production phase, because the test access pads it requires are almost free on a new layout and expensive to add later. Our PCBA IC programming service guide describes the service side, the design for testability guide covers the access requirements, and the first article inspection guide explains how the programming checkpoints fold into the first-article record. Device-level authentication and marking verification is covered in the counterfeit verification guide.
Add Programming to Your Next Assembly Order
Send the device list with the package and the current image checksum. We will tell you which programming method fits each device, what the per-unit cost is at your volume, and what the required test access looks like on the layout before you release tooling.
