Define the Identity of a Factory-Programmed Component Order

A factory-programmed component has more identity than its blank semiconductor part number. Two packages can carry the same base device while containing different software or configuration. Purchasing needs a controlled way to distinguish those states so that a correct-looking reel does not enter the wrong build.

Microchip’s programming service supports loading customer code before delivery and describes verification samples for new programs. This is a useful example of why program identity and sample approval belong in the procurement record alongside the device selection.

Create an orderable configuration record

Identify the complete base part, package, and required device revision restrictions. Add the programming file identity, release reference, and configuration settings that affect startup or operation. Do not assume that a firmware filename includes every configuration region handled by the programming process.

Define how the supplier’s programming job or custom order code maps to the internal material number. Keep that mapping available to purchasing, receiving, and assembly. A free-text note attached to one email is difficult to use when an order is repeated months later.

Review the verification sample

Choose sample tests that discriminate the intended programming state. A power-on LED might confirm basic execution while missing an incorrect communication setting or product variant. Document expected behavior and the hardware configuration used for the check. Include a deliberate test of the selected product variant.

Separate common and unit-specific data

Some builds require information that differs between devices. Define who supplies that information, which region contains it, and how completeness will be verified. Do not compare whole-device images blindly when an approved portion is intentionally unique. Keep sensitive provisioning details within the authorized process rather than including them in general assembly instructions.

1. Approve the base device and programming specification.
2. Review verification samples against product requirements.
3. Release the purchasing identity and label mapping.
4. Confirm the delivered lot references the approved job.
5. Record the installed programmed-material identity for the build.

If an image changes, assess stocked programmed devices explicitly. Some may be updateable through the product’s approved process; others may require a different disposition. Do not silently relabel an earlier programming state as the new material revision. The production image verification guide addresses the complementary checks when programming happens during assembly.