Before ordering IC programming services, specify the exact component, approved programming files, configuration settings, verification method, and required delivery state. Put those requirements under one controlled release. A manufacturer part number identifies the hardware, but your order also needs to identify the content that makes that hardware usable in the intended assembly.
For OEM and contract-manufacturing buyers, this changes the purchasing question. You are buying a defined programmed item, with a particular firmware or logic image and an agreed configuration. Procurement needs engineering to release that definition before the supplier commits a production batch to it.
Give the programmed component its own purchasing identity
Keep the complete manufacturer part number, including package and grade suffixes, in the RFQ. Add a customer-controlled identifier for the programmed version. That might be an internal part number with a revision, or a separate programming specification referenced by the purchase-order line.
The relationship should be explicit: this approved hardware, loaded according to this programming release, becomes this purchased item. Two components with identical manufacturer markings can belong to different programmed versions. Make that distinction visible in the BOM and receiving instructions.
Ask the supplier to confirm support for the exact device and package. A programmer's general support for a product family does not settle the adapter, algorithm, configuration, or verification requirements for your order. Hardware substitution and programming-file substitution should each require the designated engineering approval.
Define the IC programming service you are buying
Choose the programming stage with the assembler before requesting comparable quotations. Programming loose devices before placement can move that operation out of board assembly. Programming after assembly can keep firmware decisions closer to the final build and accommodate information generated during board calibration or configuration.
The tradeoff is when inventory becomes tied to a software release. If the image is stable and the assembler wants programmed devices at placement, offline programming may fit. If firmware changes frequently, discuss holding some material in an unprogrammed state or scheduling programming against released build demand. Confirm the physical access and process requirements with manufacturing for either route.
Describe the requested outcome precisely: blank supply, a common image on every device, individually serialized devices, or a separately defined provisioning operation. Ask which operations the supplier includes. Unique identities, cryptographic credentials, and security configuration need an agreed scope and handling method; their inclusion should be confirmed during technical review.
Release a programming package that another operator can reproduce
Send a released package rather than an attachment described as the current firmware. Engineering should identify the following inputs, as applicable:
- The target manufacturer, exact device, package, and applicable hardware revision.
- Each approved image file, its format, release identifier, and file-integrity value with the named algorithm.
- The memory map, load addresses, regions to program, and instructions for unused or preserved regions.
- Configuration words, option bytes, boot settings, and the required protection state.
- Approved programming instructions or job settings, including required tool or algorithm versions.
- Any unique-data allocation rules, approval authority, and treatment of failed devices.
Microchip's MPLAB IPE overview shows why the image alone may be insufficient: its engineering mode controls memory regions, power settings, serialization, and production permissions. Those are capabilities of that programming environment, not a universal recipe for every IC. Have the design owner release the settings applicable to the actual device.
Agree on the file-transfer route and who may authorize a replacement release. Keep the approved files and instructions together so a later email cannot silently replace one element. A repeat order should reference its intended release explicitly, even when the hardware part number is unchanged.
Separate file integrity, device verification, and final protection
A file hash can help confirm that the supplier received the same released file. Device verification addresses whether the intended content was written correctly to the specified memory regions. Ask the supplier to explain the proposed verification operation and the evidence returned for each device or batch.
If a quotation offers checksum verification, define the algorithm, covered addresses, expected result, and treatment of variable data. Serialized devices may contain deliberately different bytes. Engineering must decide how those regions are verified and which comparison remains common across the order.
Microchip's checksum guidance describes a memory-range integrity check and explains that it does not authenticate the source of the data. For purchasing, keep approval of the release separate from the operation used to check programmed content. A correctly copied file still needs an authorized release decision.
Also agree on the sequence for programming, verification, and protection. Readout restrictions can affect later inspection and rework. STMicroelectronics' readout-protection guidance describes device-dependent restrictions, erase consequences, and exceptions for certain families. Have engineering define the final state and permitted recovery path for the exact device. Avoid a generic instruction to enable maximum protection.
A hypothetical order: one flash device, two delivered versions
Suppose an OEM needs 750 pieces of the same approved flash-memory MPN. Two controller-board revisions use different released images. The quantities and identifiers below are invented to illustrate order structure; they are not Cplus product specifications or an actual transaction.
| Delivered item | Quantity | Controlled content | Intended build |
|---|---|---|---|
| Customer item FLASH-C, revision 2 | 500 | Image release 3.1 and its approved configuration | Controller hardware revision C |
| Customer item FLASH-D, revision 1 | 250 | Image release 3.2 and its approved configuration | Controller hardware revision D |
The quotation should preserve both delivered items even if the supplier purchases all 750 blank devices together. Agree on separate identification and packing for the versions. Approving a sample from FLASH-C should not automatically release FLASH-D.
Before the full programming run, agree on an initial approval quantity and the evidence engineering needs for each version. Engineering can evaluate representative programmed devices in the intended hardware. Specify whether approval units are included in the ordered quantity and whether they remain acceptable for production use after evaluation.
If release 3.3 arrives before shipment, place affected work under a defined change decision. Establish how many devices are blank, programmed, protected, or already dispatched. Then review reprogramming feasibility, repeat verification, identification changes, cost, and delivery impact before authorizing the change.
Compare quotations at the point where responsibility changes
Request separate visibility into component supply, initial engineering or adapter charges, programming setup, recurring processing, verification records, and final packing. Ask what triggers another setup charge: a new image, another configuration, a quantity split, or a later repeat order.
Clarify who supplies the blank components and who approves their source. For customer-supplied material, agree on incoming quantities, handling losses, failed-device disposition, and unused returns. For supplier-procured material, define the required condition and sourcing documentation alongside the programming scope.
Confirm when the quoted delivery period begins. Component receipt, usable release files, adapter readiness, and engineering approval may be separate dependencies. Ask the supplier to identify unresolved inputs and quote assumptions so planning can see what must happen before the batch can proceed.
Make receiving able to recognize the programmed item
Agree on container identification that connects the customer item and revision to the manufacturer MPN, quantity, programming release, and relevant job or result record. Preserve the original component identification. For serialized orders, define the delivered identity list and how rejected or unused numbers are reconciled.
Cplus's guide to tracking component lots through split shipments and PCB builds covers the underlying material trail. Add the programming release to that trail so receiving and production can distinguish hardware source identity from programmed-item identity.
Cplus lists flash-memory and programmable-logic programming among its value-added component services. To begin a relevant review, use the Cplus component requirement form, which accepts part numbers and quantities. Identify the programming requirement in the accompanying parts list or follow-up discussion, and arrange transfer of the technical package with the sourcing team.
Provide the exact MPN and package, quantity by programmed version, need date, intended programming stage, released specification identifier, and required verification and packing records. Ask Cplus to confirm device support, scope, and quotation assumptions before sending production files or committing the order.
