PCBA Programming & Serialization Handoff Guide

Q: Is a firmware SHA-256 enough to release programming?

No. It identifies the bytes but does not prove approval, authenticity, compatibility, configuration, serial uniqueness, or functional performance.

Q: Does a programming verify-passed result replace functional test?

No. Content verification, configuration, identity mapping, and functional behavior are separate controls.

Q: Can security keys be attached to the RFQ?

Do not send secrets through an ordinary RFQ attachment. Use an approved device-specific provisioning and custody workflow.

Decision summary

A firmware file by itself is not a production programming specification. Before a PCBA build is released, the customer and manufacturer should agree on the exact released image, target device and memory, programming stage and interface, equipment/fixture, security-asset custody, serial-number allocation, verification method, failure disposition, and traceability record.

The required detail depends on the product, device family, security life-cycle, production volume, customer risk, and approved toolchain. The checklist below is a handoff framework, not a universal programming recipe.

1. Identify the exact release, not only the filename

Start with one approved firmware identity:

project and assembly identifier;
released filename and firmware version;
byte count and SHA-256 digest;
build or release owner;
approval record;
effective work order, lot, or date boundary.

A filename can be renamed or reused. A cryptographic digest helps the customer and manufacturer confirm that they are discussing the same bytes, but it does not prove that the firmware is authentic, functionally correct, compatible with the assembled hardware, or approved for production. Keep those decisions separate.

This article extends the existing PCBA release-package revision-control guide. That guide controls the overall BOM/Gerber/CPL/drawing/firmware baseline; this handoff goes deeper into what must happen at the programming station.

2. Define the target and programming stage

“Program U3” is incomplete unless U3 can be tied to the released BOM, assembly drawing, and exact manufacturer part number. Record:

reference designator and device part number;
memory or configuration region;
board and assembly revision;
required device life-cycle or protection state, when applicable;
whether programming occurs before placement, after SMT, at panel level, on an individual board, during box build, or at final provisioning.

The stage changes the process risk. Pre-programmed components need material identity and inventory controls. In-circuit programming needs accessible pads or connectors, electrical limits, and a fixture. Final provisioning may need a network service or customer-controlled credentials. Do not move the stage without an approved process change.

3. Specify the interface, fixture and production equipment

Name the interface and connection definition. Depending on the device, a project may use SWD, JTAG, UART, ISP, a bootloader interface, or another supported method. The handoff should include:

connector or test-pad map and pinout;
ground reference, voltage and current limits;
reset, boot-mode, power-up, and connection sequence;
cable or fixture identity and ownership;
programmer hardware, software, script, and configuration versions;
expected cycle-time range for capacity planning, without turning an estimate into a guaranteed limit.

Development utilities are not automatically suitable or licensed for volume production. STMicroelectronics, for example, distinguishes development programming from production programming and recommends supported production partners for factory use. Tool approval must therefore be checked for the exact production environment rather than inferred from a successful engineering-board test.

The functional-test fixture handoff guide remains the canonical topic for fixture coverage, golden units, test limits, maintenance, and ownership. The programming guide should link to it but should not repeat its test-fixture sections.

4. Separate confidential assets from the manufacturing package

Secure provisioning may involve firmware encryption, signing material, certificates, device credentials, one-time-programmable settings, or irreversible life-cycle changes. The handoff must state:

who owns each asset;
what the manufacturer is permitted to receive;
what must remain under customer or approved third-party control;
how the factory receives an approved manufacturing package;
package expiry, revocation, or replacement rules;
which audit record is returned;
who can authorize an irreversible security-state change.

Do not place plaintext secrets in a general RFQ attachment or ordinary checklist. NXP documents device-supported trust-provisioning workflows in which a contract manufacturer can provision firmware without access to OEM confidential assets and can produce per-device audit records. That is evidence that asset isolation is possible in supported workflows, not evidence that every device or EMS process provides it.

The customer should approve the exact security method for the selected silicon and production toolchain. The manufacturer should not invent a key-transfer method to fill a missing instruction.

5. Define serialization as a controlled allocation process

Serialization needs more than a number printed on a label. Agree on:

whether identity is class-, batch/lot-, or instance-level;
the authoritative allocator: customer list, controlled range, database, or approved service;
uniqueness scope: project, product family, customer estate, or external scheme;
string pattern, length, allowed characters, and leading-zero handling;
quantity and permitted range;
device memory address or application field;
mapping to a 1D/2D code, PCB label, enclosure label, or system database;
when an identifier is considered consumed;
how duplicates, skipped values, retries, replacements, and scrapped units are recorded.

Microchip SQTP is one example of programming a unique value into each device from a serial-number file. Its file format and memory constraints are specific to the supported Microchip workflow and must not be generalized to other devices.

GS1 distinguishes class-, batch/lot-, and instance-level identity. If a project uses a GS1-based identifier, treat it as a string and preserve significant leading zeroes. If the customer uses an internal scheme, do not describe it as globally unique without evidence.

6. Separate four kinds of verification

A robust release distinguishes:

Byte/content verification — the programmed memory matches the intended buffer or image according to the approved tool.
Configuration verification — required option bytes, fuses, locks, certificates, or life-cycle states are correct where applicable.
Identity verification — the programmed serial matches the label and traceability record, with no duplicate allocation.
Functional confirmation — the assembled product starts and behaves as required under the approved functional test.

ST documents program-content verification and reports checksum/first-error information in its programming environment. That supports recording a concrete verify result; it does not make a checksum evidence of authenticity, configuration correctness, serial uniqueness, or functional behavior.

Define a retry ceiling and failure path before production. A failed unit should not silently consume multiple serials, be repeatedly programmed without review, or re-enter the lot with an ambiguous history. Specify quarantine, investigation, authorized rework, serial disposition, retest, and final release authority.

7. Link the result to production traceability

For each required identity level, decide which records must be retrievable. A programming record may include:

board or serial identity;
lot/work order and assembly revision;
firmware filename, version, and digest;
programming station, programmer, fixture, script, and configuration identity;
timestamp and result;
operator or automated-process identity;
programmed serial and label/code mapping;
configuration/security-state result where approved;
retry, failure, rework, and final disposition;
functional-test linkage.

IPC describes manufacturing and supply-chain traceability as risk-based and agreed between user and supplier. Do not present one fixed record set or retention period as universally compliant. Define the contractual scope, retention, access control, export format, and retrieval expectation for the project.

The PCBA traceability data guide remains the canonical broader topic for material genealogy, process records, test data, rework, and shipment linkage. This programming article should contribute programming-specific fields to that framework.

8. Programming and serialization handoff checklist

Before the line is released, confirm:

exact assembly, device, and programming stage are identified;
released image version, byte count, SHA-256, and approval reference agree;
interface, pinout, power limits, fixture, programmer, software, and script are controlled;
development-tool versus production-tool suitability is resolved;
confidential-asset custody and manufacturing-package boundaries are approved;
irreversible security actions have explicit authority;
serial scheme, allocator, uniqueness scope, format, range, and leading-zero rules are defined;
device, PCB label, enclosure label, and database mapping are defined;
content, configuration, identity, and functional verification are separately specified;
retry, quarantine, rework, and serial-disposition rules are approved;
traceability fields, retention, access, and export format are agreed;
effective work order or lot boundary is recorded.

Download the Programming and Serialization Handoff Sheet to make these decisions reviewable before quote, fixture design, pilot build, and production release.

Frequently asked questions

Is a firmware SHA-256 enough to release programming?

No. It helps identify the exact bytes but does not prove customer approval, authenticity, hardware compatibility, configuration state, serial uniqueness, or functional performance.

Should the manufacturer generate serial numbers?

Only when the customer has approved the allocator, uniqueness scope, format, consumption rules, record ownership, and exception process. Otherwise the authoritative serial source must remain explicit.

Does a programming “verify passed” result replace functional test?

No. Content verification and functional behavior answer different questions. Configuration, identity mapping, and security-state verification may also be separate requirements.

Can security keys be attached to the RFQ?

Do not send secrets through an ordinary RFQ attachment. Define an approved device-specific provisioning and custody workflow with the customer security owner and authorized production parties.

Turn the handoff into a controlled build plan

Use the downloadable sheet with the PCB assembly RFQ checklist, first-article inspection guide, and technical resource library. For a project review, submit the non-secret programming requirements through the PCBA RFQ page; confidential assets should follow the separately approved security workflow.

Primary references

Download the Programming and Serialization Handoff Sheet (XLSX)