Table of Contents
A preprogrammed microcontroller is two controlled items delivered together: an exact semiconductor and an exact programmed state. An order can contain the right silicon and still fail production because a configuration bit, bootloader, calibration field, or serial-number range is wrong.
Treat programming as a released manufacturing process. The procurement package should state what will be programmed, how it will be verified, and how each delivered unit remains connected to that release.
Two identities on one purchase line
Use the full manufacturer ordering code for the semiconductor. Add a distinct internal identifier for the programmed assembly or service configuration, linked to the firmware version and programming job.
Microchip’s programming service, checked September 15, 2026, supports adding customer code to applicable devices and describes verification samples and optional handling services. This establishes an available manufacturer workflow, not a claim that every MCU or security configuration is supported.
Confirm support for the exact device, binary format, configuration, and quantity with the chosen programming provider. A distributor SKU should not become the only surviving description of what was loaded.
The programming release package
| Release item | Purpose |
|---|---|
| Exact device code and permitted revision | Defines the silicon target |
| Binary, version, and cryptographic hash | Identifies the approved common code |
| Address map and file interpretation | Prevents wrong-region or offset programming |
| Configuration and option settings | Defines boot, clock, protection, and other persistent choices |
| Variable-data specification | Separates serial numbers and calibration from common code |
| Programming and verification sequence | Makes the process reproducible |
| Accepted sample record | Connects the job to board-level approval |
| Label and shipment mapping | Connects delivered material to the release |
A hash detects a difference between files; it does not prove that the approved file is functionally correct. Keep the software release and hardware acceptance decisions alongside it.
Avoid sending passwords or private keys inside an ordinary BOM spreadsheet. If secure provisioning is required, use the approved provisioning architecture and provider process. An ordinary firmware-programming service should not be assumed to provide every required key-protection function.
Serialization reconciliation
Serial numbers introduce per-unit content. Define the allowed range, generation authority, uniqueness rules, handling of failed programming attempts, and whether a failed unit’s identifier can ever be reused.
An illustrative job may allocate 1,000 identifiers and deliver 980 accepted devices after 20 rejects. The final record should account for all 1,000 identifiers, including the disposition of the rejected units. Shipping 980 devices without that reconciliation can leave duplicate or orphaned identities in the system.
The common firmware region can have one verification value while serialized regions differ. Specify those scopes explicitly so a legitimate per-unit difference is not mistaken for corrupted code.
The IoT prototype-to-production guide covers the broader manufacturing transition; this release record controls the programmed content within it.
Sample approval and protection settings
Evaluate representative programmed samples on the released board. Check startup without a debugger, intended clock configuration, communication interfaces, update path, reset behavior, and access restrictions.
Protection settings can change what later verification or rework is possible. Define the sequence for programming, verification, locking, and final functional checks using the device’s supported procedure. Do not assume a field return can be erased or read back after security settings are applied.
If programming occurs in circuit, the board connection is part of the process. Microchip’s custom-PCB programming-interface guidance illustrates that programming signals can share device pins and require a compatible board interface.
Firmware changes and returned material
A new firmware revision should create a new controlled programming job or an explicitly revised one. Define how old and new material are segregated, whether old stock may be reprogrammed, and who approves any mixed shipment.
Retain programming results, device lot identity, release version, variable-data reconciliation, and final label mapping. For unused material returned from an assembler, preserve its programmed identity instead of returning it to a bin of nominally identical blank devices.
In a BOM sourcing package, state whether the line item is blank or programmed and identify the release owner. For IoT products, that distinction protects both production continuity and future serviceability.
A correct programmed order is one whose silicon, code, configuration, and per-unit data all match a release that the product team can reproduce.
Frequently Asked Questions (FAQ)
Is a firmware filename enough to specify a programmed MCU?
No. Include the approved binary and hash, target ordering code, programming settings, configuration bits, version, and verification procedure. A filename can be reused or point to the wrong build.
Should every serialized unit have the same full-image hash?
Not if per-device fields differ. Define how the common image is verified and how serial numbers or other variable fields are checked and reconciled separately.
Does successful programming prove the board will boot?
No. Programming verification confirms the specified programming operation within its scope. Board-level startup, configuration, interfaces, and application behavior need their own acceptance checks.
