How to Prepare Firmware for Production Programming
To prepare firmware for production programming, supply the approved image together with the target device, memory configuration, connection diagram, tool settings and verification procedure. Include instructions for failed cycles. An operator should be able to program the correct device from that package without access to the developer’s bench setup.
Programming is distinct from functional testing. Successful transfer or readback does not show that an assembled product meets its operating requirements. Plan both operations, using the functional test fixture checklist for the wider test station.
Identify the firmware image and supported hardware
Name the approved firmware version, supported board revisions and exact target device. List every programmed region, including the bootloader, application and configuration data where applicable. Specify the file format and destination addresses. For a raw binary, supply the load address separately rather than expecting the programmer to infer it from the file.
Record a cryptographic file hash to identify the released artifact. A hash detects an unexpected file change; it does not establish that the firmware is correct or approved. Keep the approval record with the artifact and do not allow an operator to substitute an untracked rebuild from the same source branch.
Make the programming station reproducible
Specify the programmer, software version, required licenses, interface, connector pinout and target voltage. State whether the programmer supplies power or connects to a separately powered board. Check for competing power sources and connections that remain energized when the fixture is open.
Include reset and boot-mode requirements, the approved device configuration and how the tool identifies the target. Do not assume a development probe or freely downloadable utility is licensed or qualified for the planned production use. Device support and security behavior must be checked against the selected vendor’s current documentation.
List the files and station settings in a release manifest
Use the fields below to assemble the release manifest. Take addresses, voltages and security settings from the approved design and the exact device documentation.
| Manifest field | Required content | Reject or hold when |
|---|---|---|
| Hardware applicability | Assembly number, board revision, device and configuration | The board revision is not explicitly supported. |
| Images | Filename, version, file hash, format and destination region | Files disagree with the approved manifest. |
| Station | Tool, software, fixture and procedure revisions | A different setup is used without qualification. |
| Electrical connection | Pinout, power source, interface levels, reset and boot control | It is unclear which device supplies power or drives a signal. |
| Per-unit data | Source, allocation rule and protected storage region | An identifier is duplicated or unallocated. |
| Acceptance | Programming verification, separate functional checks and records | A tool reports success but required evidence is absent. |
Separate common firmware from unique device data
Serial numbers, calibration values and credentials may differ for every unit. Specify which system allocates them and how they are associated with the physical board. Reprogramming must not silently duplicate another unit’s identity or erase calibration that should be retained.
Define what happens if a cycle fails after an identifier has been allocated. Keep the programming-cycle counter distinct from the product serial number unless the procedure explicitly links them. SEGGER documents serial-number programming and per-cycle logs, including configuration options that affect these records. Verify that the intended identifier was written to the target, rather than relying only on its presence in a log.
Approve the verification and retry sequence
Specify the tool’s available verification operation and its expected result. Where read protection prevents later readback, the approved flow must establish verification before protection is applied, or use the supported alternative evidence. Irreversible fuses, lifecycle transitions and security settings require explicit authorization; they are not routine fixes for a connection error.
Specify the permitted number of retries, when to remove a board from the station, and who reviews the failure. Keep failed attempts as well as the final result. Each record should identify the board, firmware version, image hash, station and procedure revisions, timestamp, result and any approved deviation.
Before the batch, have the receiving team execute the released instructions on an authorized unit and review the records. A known-good unit helps check the station, but it cannot substitute for defined electrical limits or demonstrate all product functions.
Include this package in the manufacturing handoff and agree on the programming and verification scope before assembly starts.
Cover image: AI-generated editorial illustration, not a production record or an acceptance reference.
