SPI Flash Memory Programming Process for Electronic Manufacturing

External SPI Flash memory is found in industrial equipment, IoT gateways, automotive systems, network devices, embedded Linux platforms, and FPGA boards. It can store anything from configuration tables to the complete code that allows the product to boot. For this reason, Programming an SPI Flash in production is not simply a matter of copying a binary file.: requires checking the correct device, memory map, power supply, protection registers, internal erase and write times, signal integrity, and verification evidence.

A perfectly good file can still produce a faulty drive if it's loaded at the wrong offset, if a reserved area is erased, or if the programmer shares the bus with a processor that remains active. Similarly, an operation that ends with the message "PASS" may not be sufficient if the boot, version, device identifier, and contents of critical regions are not verified.

This guide describes a reproducible process for SPI Flash programming in manufacturing, From image preparation to post-burning validation. The commands and sizes shown are common in SPI NOR memories, but should always be confirmed against the datasheet for the exact part number.

External SPI Flash vs. Internal Microcontroller Flash

The internal Flash memory is manufactured within the same package as the microcontroller and is typically programmed via a debug interface or boot ROM, such as SWD, JTAG, or UART. The MCU manufacturer defines the erase algorithm, security regions, address map, and protection mechanisms.

The External SPI Flash It is a separate circuit connected to the host via SPI, Dual SPI, Quad SPI, or Octal SPI. The processor can read it as data storage, copy its contents to RAM during boot, or execute code directly from it using XIP. It can also act as configuration memory for an FPGA or CPLD.

This difference necessitates treating the SPI Flash as its own subsystem. Before performing any destructive operation, the programmer must know the correct voltage, density, page size, erase geometry, addressing mode, and protection status.

What does a production image contain?

In simple products, the image may be a single firmware file starting at address zero. In more complex systems, memory contains several independent regions. A typical production image may include a bootloader, one or two application banks, a partition table, configuration data, certificates, graphical resources, radius parameters and calibration constants.

Renesas documentation shows, for example, multi-part images in which the bootloader, application banks, configuration, and product header are placed at specific offsets. Changing one of those offsets without updating the boot software can prevent the device from finding a valid image.1]

The file format also matters. A file BIN It contains a byte sequence with no address information; therefore, the programming project must provide the starting offset. Intel HEX, Motorola S-record, and ELF can preserve addresses or segments. Production tools such as J-Flash SPI support BIN, HEX, SREC, ELF, and other formats, but compatibility does not eliminate the obligation to validate addresses, gaps, and final size.2]

Before releasing an image, it's advisable to generate a manifest that includes the name, version, size, offset of each region, cryptographic hash, compatible memory reference, and final protection policy. The image should be built reproducibly and maintained under version control.

Secure sequence: identify, erase, schedule, and verify

A NOR cell can be programmed from "1" to "0", but it requires an erase cycle to return from "0" to "1". Therefore, the process must respect the device's geometry. Many memories commonly use 256-byte pages and 4 KiB sectors, although these should not be assumed to be universal. Sending data beyond the page boundary can produce wrap-around in certain references and overwrite the beginning of the same page.[3]

The recommended production sequence includes the following controls:

1. Stabilize the diet. Apply the nominal voltage with current limit and wait for the specified power-up time.
2. Identify the device. Read JEDEC ID using RDID and, when available, query SFDP. The JESD216 standard defines an internal database that describes memory parameters.4]
3. Read status and configuration logs. Register protection, Quad Enable, address mode, and other bits that influence access.
4. Run blank check or compare. Determine if the affected areas are already empty or match the image.
5. Unlock only what is necessary. Temporarily clear any protections that prevent the deletion of authorized regions.
6. Delete by sector or block. Avoid Chip Erase when there is factory or calibration data that needs to be preserved.
7. Program respecting pages and offsets. Divide the image into valid transactions and do not cross page boundaries.
8. Verify by reading. Compare byte by byte or by blocks and calculate CRC or hash over the expected range.
9. Restore protection. Configure boot sectors and reserved zones according to the product policy.
10. Perform a startup test. Confirm that the host identifies the Flash, locates the image, and runs the correct firmware.

Each operation involving deletion, programming, or modification of records must be preceded by Write Enable. Next, the device must read the WEL bit to confirm that the command was accepted and poll WIP/BUSY until the internal operation is complete. Replacing this polling with a fixed delay is risky: the actual timing varies with voltage, temperature, wear, and semiconductor batch.

Clock speed, signal integrity, and wiring

A memory module whose datasheet advertises read speeds of tens or hundreds of megahertz cannot necessarily be programmed to that frequency in a fixture. The chip's maximum frequency is measured under controlled conditions; the production facility adds cables, connectors, pogo pins, adapters, stubs, and imperfect return planes.

The typical failure is intermittent: the device correctly reads the JEDEC ID at low speed, but encounters verification errors when the SCK value increases. It may also function with a cold board and fail after several cycles. The problem lies not in the file itself, but in the electrical margin of the link.

The process qualification should aim for a robust frequency, not the maximum value. It is recommended to check SCK, CS#, MOSI, and MISO with an oscilloscope at the point closest to the component, verify that the voltage remains within range during erasure, and document the maximum fixture length. If the margin only exists when drastically reducing the frequency, the problem must be resolved in the access design or the fixture, not masked by increasing retries.

Sector protection and status registers

SPI NOR memories typically include block protection bits and locking mechanisms. In Winbond families, for example, the BP bits select a protected fraction; SEC changes the granularity to sectors; TB chooses whether the protection starts at the top or bottom; and CMP can complement the region. The WP# pin can prevent modification of the registers that govern the protection, instead of directly locking all data.5]

This detail explains many misdiagnoses. An operator might interpret an "erase failed" as device damage when they are actually trying to write to a protected region. Conversely, deleting all protection records without logging their status can leave the boot code exposed upon completion of the process.

Permanent locks or OTPs require special caution. They should only be applied after completing verification, boot testing, and approving the update policy. An irreversible lock applied to the wrong image renders functional memory unrecoverable.

In-circuit programming versus socket programming

Socket programming works with the component before assembly. The programmer directly controls VCC, CS#, SCK, MOSI, MISO, WP#, and HOLD#/RESET#. This simplifies diagnostics and avoids interference from the host. Furthermore, it allows the use of gang stations and the parallel loading of multiple memories.

In-circuit programming eliminates the need for additional component handling and allows the Flash memory to be associated with the PCB's serial bus. However, the SPI bus is already connected to the microprocessor, FPGA, or other peripherals. If the host is partially powered or its outputs are not at high impedance, it can drive the same lines as the programmer, causing contention.

For direct-to-memory ISPs, the design must allow the host to be kept in reset, control the chip selects of other slaves, and prevent simultaneous power from two sources. Series resistors, jumpers, tri-state buffers, or analog switches can provide isolation. Direct programming tools can access the Flash without relying on the host processor, but the electrical design remains the responsibility of the system.6]

Validation after engraving

The verification must confirm four different dimensions: identity, content, configuration and function. Reading the JEDEC ID confirms that the device is responding and that its density matches the project. Byte-by-byte comparison confirms that the programmed range matches the image. A CRC or hash allows for recording a compact fingerprint of the content. Reading the status registers confirms that the address mode and protection are in the expected state.

Finally, the boot test validates something that no memory comparison can demonstrate on its own: that the processor correctly interprets the header, offsets, read mode, dummy cycles, and image structure. When the product uses digital signatures, the hash demonstrates integrity, but authenticity is only confirmed by verifying the signature against a root of trust.

Minimum evidence per unit must include the programmer ID, memory part number, JEDEC ID read, image version, expected hash, verify result, final records, date, time, and product serial number. This data transforms an isolated "PASS" into a traceable manufacturing record.

Errors that should block the release

An operation must be stopped if the read density does not match the design, if the BIN exceeds memory, if the offset is not documented, if there is an unbacked reserved region, if the host cannot be isolated from the bus, or if the verification fails even once. Indefinite retries should also not be accepted as a solution: a robust process identifies the electrical, logical, or configuration cause.

Among the most costly risks are flashing an image to the wrong hardware revision; deleting MAC addresses, serial numbers, calibration keys, or other keys; modifying Quad Enable or 3/4-byte mode without considering the boot ROM; and cutting power while WIP is still active. All of these are preventable through pre-identification, address limits, approved manifests, qualified fixtures, and functional validation.

Learn more

To expand on the fundamentals and consult primary documentation, review the following resources:

• JEDEC JESD216H: Serial Flash Discoverable Parameters (SFDP).
• SEGGER J-Flash SPI: programming, erasing, verifying, and readback.
• Winbond: protection of boot code and critical data in SPI NOR.
• Non-Volatile Memories in Embedded Systems: Flash, EEPROM, eMMC and UFS.
• In-System Programming vs IC Preprogramming.

References

1. Renesas — Images and binaries.
2. SEGGER — J-Flash SPI Knowledge Base.
3. Bus Pirate — W25QXXX NOR Flash Chips SPI.
4. JEDEC — JESD216H Serial Flash Discoverable Parameters.
5. Winbond — Safeguarding boot code and other critical data.
6. Corelis—SPI Flash Programming.