Firmware Validation and Configuration After Programming an IC

In a programming station, the word PASS This is often interpreted as definitive confirmation: the firmware was loaded and the integrated circuit is ready for production. However, this result only demonstrates that the procedure executed certain steps without detecting a fault condition. It does not necessarily confirm that the correct image was used, that the memory map was interpreted correctly, that the fuses remained in the expected state, or that the device will boot when the programmer is removed.

Post-programming verification must answer a broader question: Does this unit contain the correct firmware, identity, and configuration, and can it perform its minimum function under actual boot conditions? To answer it, methods with different coverages are combined: verify during the process, readback, checksum, CRC, cryptographic hash, digital signature, configuration reading and functional testing.

No single method covers all risks. A byte-by-byte comparison can confirm content, but it doesn't prove the drive will boot. A CRC can quickly detect changes, but it doesn't authenticate the firmware author. A functional test can confirm communication and power consumption, but it could run on the wrong revision if the image identifier isn't validated. Quality control results from combining independent layers.

Programming is not validation: what a “PASS” can hide”

The first risk is the wrong reference. The file may be technically valid and programmable without errors, but correspond to a different hardware revision, market, or product variant. The station will report PASS because it wrote exactly what was requested; the problem lies in the recipe selection.

The second risk is a incorrect shared interpretation. Keysight documents that the Program and Verify routines can use the same data register. If both misinterpret the source, Verify may approve incorrect content. The company recommends a CRC separate from the program register, provided the reference value comes from a known correct unit.1]

There may also be a incomplete scope. One operation checks only the addresses present in the file, but leaves other regions of the device unchecked. These regions could contain data from a previous programming, incorrect calibration values, or unexpected content. In other cases, the firmware is compared correctly, but option bytes, fuses, lock bits, or OTP pages are excluded from the validation.

What each verification method checks

The terms verify, readback, checksum, CRC, and hash are often used interchangeably. They are not. Each one addresses the validation problem differently, with varying probabilities of error detection, time requirements, and security properties.

Verify during programming

Traditional verifying reads each cell, word, or block and compares it to the object file. It is the most direct way to detect different bytes within the programmed range. PEmicro describes this byte-by-byte comparison as the standard mechanism and differentiates this verification from CRC-based methods.2]

Its main strength is localization: it can pinpoint the exact location of the first mismatch. Its limitation is the scope defined by the recipe. If the project omits a region or mistakenly expects data in another direction, the verify function will not correct that engineering error.

Readback

Readback extracts the contents of the IC and saves or transmits them for independent analysis. It can be compared to the master image, used to investigate a failed unit, or retained as original piece evidence. Its advantage is separating acquisition from analysis; its cost is the readback time and the secure handling of sensitive information.

Readback is not always available. Read protection may block it after applying lock bits, and some devices only allow access to specific areas. Therefore, if the plan requires read evidence, it must be executed. before of irreversible protection. In addition, the extracted files must be controlled as intellectual property and removed from temporary storage locations when the analysis is complete.

Checksum and CRC

An arithmetic checksum summarizes data using a simple operation. It can detect many common errors, but offers less detection capability than a well-chosen CRC. CRC It applies polynomial division and is designed to identify accidental alterations, including burst error patterns. For the result to be comparable, the polynomial, initial value, reflection, final XOR, address range, and byte order must match.

PEmicro documents CRC-16 checks on addresses present in the file and on the entire device. The latter can detect unexpected content even in regions not programmed by the object. It can also be faster than a byte-by-byte comparison when the debug link is slow.2]

A CRC does not prove authenticity, nor is it invulnerable to deliberate modification. Its value in production is to efficiently detect accidental corruption. The expected value should be calculated from the approved master artifact; "learning" the CRC from an unvalidated unit can turn a defect into a new reference.

Cryptographic hash and digital signature

A hash like SHA-256 generates a digest that changes when the message is modified. NIST FIPS 180-4 defines secure hash algorithms whose digests are used to detect if messages have changed since they were calculated.3In a manufacturing process, the hash can link the released file, the programmer's recipe, and the content read from the device.

The hash confirms equality against a trusted reference, but does not prove who authorized the image. The digital signature adds authentication of origin, integrity, and non-repudiation when implemented correctly, according to the NIST definition.4Therefore, CRC and hash primarily address integrity; digital signatures address both integrity and authenticity.

Validation of fuses, option bytes, lock bits, and unique data

Firmware is not the only information that defines the behavior of an IC. In different families, the non-volatile configuration can select the clock source, watchdog timer, boot mode, read protection, write protection, brownout, debug mode, and memory layout.

ST explains that the option bytes are located in a different region of the user Flash and can be loaded after a power-on reset or through a specific mechanism. A software reset or the NRST signal does not necessarily make the new values effective. Validation must read the configuration loaded into the device, not simply confirm that the write operation is complete.5]

Microchip notes that AVR fuses define hardware configurations such as clock, watchdog, and debug; an incorrect selection can render the MCU unprogrammable or undebuggable in the application. It also warns that certain lock bits prevent modification of the fuses, so the correct order is to program and verify the configuration before applying the lock.6]

The same discipline applies to serial numbers, MAC addresses, certificates, keys, and calibrations. Each value must have an authorized source, a valid range, and an unambiguous relationship to the unit. The station must verify that the identifier is not duplicated, that the write occurs in the intended direction, and that the readback matches before confirming the value's consumption in the database.

Minimal functional testing after programming

Functional testing is not intended to replace ICT, system testing, or design validation. Its objective is to demonstrate that the programmed IC starts under representative conditions and that the essential functions for continued manufacturing are available.

The first step is to remove the special programming conditions. The debugger must release the reset, the boot pins must return to their default state, and power must cycle when the configuration is loaded on power-on. This prevents approving a unit that only functions while the programmer holds a signal or keeps a power domain active.

Limits must be defined for each product and statistically validated; simply copying a generic current window is not advisable. A measurement that is too wide will not detect anomalies, and one that is too narrow may miss normal component variations, temperature differences, or power supply tolerances.

Results and traceability: what to record

A PASS log should allow for the reconstruction of what happened without relying on the operator's memory. IPC identifies IPC-1782 as the traceability standard for the manufacturing and supply chain of electronic products.7The level of detail required depends on the product risk, but the association between unit, process and result must be unambiguous.

For each unit, it is advisable to record the UID or serial number, IC part number and revision, JEDEC ID or device ID, image name and hash, algorithm recipe and version, configuration values, injected serials or calibrations, verify result, CRC or hash read, functional result, fault code, equipment, fixture, authorized operator or session, and timestamp.

For each batch, the following information must be retained: work order, semiconductor batch number, quantity received, scheduled, approved, rejected, and pending, recipe changes, first piece, golden sample used, and quality release. The record must be immutable or maintain a history of changes; correcting data should not delete the previous value or the identity of the person who made the modification.

Fault management, quarantine, and rescheduling limits

A unit with a mismatch, unexpected configuration, or functional failure should not automatically return to the beginning of the cycle. Indiscriminate retrying can turn an intermittent fixture failure into an apparent PASS, erase diagnostic evidence, or consume write cycles without resolving the cause.

The correct flow begins with physical and logical quarantine. The error code, the step where it occurred, voltages, current, readback allowed, socket number, and fixture status must be preserved. Then, the probable cause is classified: file or recipe, device, mechanical contact, power supply, signal integrity, safety lock, or assembly failure.

Reprogramming may be authorized when the device remains accessible, irreversible protections have not been applied, unique data has not been consumed inconsistently, and the rework limit is defined. It must be prohibited when there is duplicate identity, evidence of electrical damage, an incorrect irreversible lock, or incomplete traceability. Each rework operation must create a new event; it should never replace the original record.

Example of a control plan for a production batch

The following example presents an adaptable structure for a batch of microcontrollers with firmware, option bytes, and serialization. It does not replace the datasheet, product specification, or approved quality plan.

For critical products, changes to firmware, algorithms, fixtures, sockets, or power supplies should trigger a new first part. Failure trends by socket and station should also be reviewed: an increasing retrieval rate may anticipate wear before permanent rejections occur.

A layered validation strategy

The most robust way to avoid “apparently programmed” units is to separate the quality checks. First, the IC's identity is confirmed. Then, the contents are checked for within and outside the relevant ranges. Next, the configuration and unique data are read. Finally, the behavior after a real reset is tested.

This independence reduces blind spots. If Program and Verify share a misinterpretation, an independent hash or boot test can detect the discrepancy. If the content is correct but the fuses are incorrect, subsequent reading and power cycle testing will reveal the problem. If all values are correct but the hardware fails to boot, the functional test prevents the unit from proceeding.

The goal is not to routinely accumulate evidence, but to design risk-proportional coverage with controlled master references, clear limits, and a defined response. In electronic production, Firmware quality doesn't end when the last byte is written; it ends when the drive demonstrates that it contains, protects, and executes the correct configuration..

Learn more

• Firmware Security in Manufacturing: Intellectual Property Protection.
• IC Serialization: Traceability and Control in Electronic Manufacturing.
• NIST FIPS 180-4: Secure Hash Standard.
• PEmicro: Verify a Programmed Device via Checksum.
• Global Electronics Association: IPC-1782 and Digital Manufacturing.

References

1. Keysight — How do the Flash RAM Program, Verify and CRC tests interact?
2. PEmicro — Verify a Programmed Device via Checksum
3. NIST—FIPS 180-4 Secure Hash Standard
4. NIST CSRC—Digital Signature Glossary
5. STMicroelectronics — What option bytes in STM32 are, and how to use them
6. Microchip — 8-bit AVR Microcontrollers Fuses
7. Global Electronics Association—Digital Manufacturing and IPC-1782