Define the release at the product level
A filename such as final.bin leaves essential questions open: which hardware can run it, which configuration is allowed, and which build may use it? Put those decisions in a controlled release record. The record can be a reviewed document or a managed system entry; it needs an owner and a traceable approval state.
Hardware, BOM, firmware and test documents can have different revision identifiers. A release manifest connects the approved combination. For example, a product release could reference PCB revision C, assembly drawing A7, firmware 1.4.2 and test sequence F6. These identifiers are illustrative, not a Keep Best customer record.
Use a programming release manifest
| Release field | What the owner should specify | Question to resolve before use |
|---|---|---|
| Product and applicability | Product/variant, compatible hardware and any component-dependent restrictions | Can this image be used on every board in the proposed lot? |
| Image identity | Controlled artifact location, version/build identifier and file digest where used | Which exact bytes were approved, and who approved them? |
| Programming configuration | Supported production tool, interface, settings and fixture revision | Does the station use the released configuration rather than an engineer’s local default? |
| Verification method | Device-supported write verification, readback or other approved integrity evidence | What can the verification establish under the chosen protection state? |
| Unit identity | Serial allocation owner and required product/board/device-ID association | How are duplicates, skipped identifiers and replacements handled? |
| Post-program checks | Required startup, configuration and functional checks with limits | Which checks must pass before the unit advances? |
| Authorization and effectivity | Approver, applicable builds and withdrawal/supersession rule | When must the station stop using the previous release? |
A file digest helps identify an artifact. A digest alone does not establish who authorized the image or whether the product will function correctly. Where the design requires signed images or an authenticated release channel, include the approved verification route rather than substituting a checksum for authorization.
Keep programming verification and product testing separate
Successful data transfer, a programming verification result and a functional-test pass are different records. A board may contain the intended image while carrying the wrong variant settings, an incomplete calibration record or an installation problem. Define the evidence required for each step and keep it associated with the same unit or agreed traceability level.
Device protection can affect which memory operations are available. Use the manufacturer-supported method and the approved programming sequence for that device. Do not relax security settings merely to make a generic readback routine pass. Confirm any irreversible configuration step with the product authority before releasing the station procedure.
STMicroelectronics’ programming guidance distinguishes development programming from production programming and calls for production-grade tooling. Check device support and current tool terms for the actual process; this guide does not select a programmer or claim that Keep Best uses a particular vendor’s software.
Preserve failed attempts and authorized rework
| Observed event | Controlled response | Evidence to preserve |
|---|---|---|
| Write or integrity verification fails | Hold the unit and investigate the recorded failure before an authorized repeat | Original result, station/tool setup, artifact identity and subsequent attempts |
| Programming passes but functional test fails | Keep the failure classification open; investigate software, configuration and hardware as applicable | Programming result plus the failed functional step and conditions |
| Duplicate or mismatched serial identity | Stop release of affected units and reconcile the identity records | Allocated ID, observed ID, affected unit list and approved disposition |
| Firmware is superseded during a build | Identify affected work in progress and finished stock, then obtain a disposition | Old/new release IDs, effectivity and any reprogram/retest authorization |
| A unit is reprogrammed after final test | Repeat the applicable checks under the approved procedure | Original identity and test history, replacement image and final release evidence |
Repeated retries should have a defined limit or escalation rule in the work instruction. Retain the original failure; a later pass should not erase the path taken to reach it. Access to credentials, keys and customer configuration also needs an authorized provisioning owner. Routine reports should contain the necessary references and results without exposing secret values.
Agree a useful unit record
A practical record identifies the unit or lot, product and hardware variant, firmware artifact, programming configuration, station, attempt result and the applicable test result. Add timestamps and operator or automated-station identity as required by the agreed record policy. Decide which system owns the association and what is delivered with the order.
For example, a board that is reprogrammed after a repair should retain a link from the original programming attempt through the approved action to the final test and release. This is an illustrative record flow, not a claim about a customer program. The quality evidence requirements help define the traceability level for an actual project.
Bring programming into the manufacturing handoff
Include the released image, compatibility statement, programming instructions, existing assets and unresolved questions in the design transfer package. For a product assembled into an enclosure, confirm where programming occurs in the box build sequence and which inspection and test checks follow it.
For connected-device software updates, IETF RFC 9124 discusses firmware-manifest information such as applicability and image integrity. It is an informational document about update systems, not a universal factory programming specification.
Discuss the programming work package with the product stage, quantities, device family and files available. Flag missing approvals or test assets early; sensitive firmware and provisioning details can follow through an agreed exchange route.