Second-sourcing the SPI flash on a board

A purchasing question arrives with two part numbers: the flash already on the board and a proposed replacement. Both have the same advertised capacity and a similar package — the same trap “same value, same size” sets for a substitute ceramic capacitor. The tempting answer is to buy a few, program one, and accept the substitute if the application starts.

That is useful initial evidence, but it leaves much of the product untested. The programming station, startup code, firmware updater and application can each access the flash differently. A replacement needs to work through that complete chain, including recovery after an interrupted update.

This note describes a review plan for second-sourcing SPI NOR flash. It is not a list of interchangeable parts. The decision depends on the exact ordering codes, board design and software versions in the product.

Start with the board and the exact package

Record the existing part number with every suffix, the proposed part number, and the board revision. Compare their supply and I/O requirements, operating conditions, pin assignments, package drawings and recommended land patterns before fitting samples. A shared family name or pin count does not establish compatibility.

Check what each signal does during startup and reset as well as during normal transfers. Pins that carry extra data lanes in one mode may have control functions in another. The board’s pull resistors, MCU startup state and reset sequence are part of the comparison.

Do not assume a footprint for a wider body accepts a narrower one. Compare the actual lead geometry and pad overlap for each candidate. If a package includes an exposed pad, follow that candidate’s connection requirements. Any proposed shared footprint needs its own assembly review.

The same care applies to electrical limits. The existing clock frequency and board layout are inputs to qualification, not proof that a substitute can operate at the same settings. Record the relevant limits from each candidate’s documentation so the decision can be reviewed later.

Identify the software assumptions

Many drivers support several flash families, but a working driver is not necessarily configured for every candidate. Capture the MCU, controller, framework version, bootloader, flash-driver configuration and production programming tool in the review package.

Quad-mode setup is one example of a vendor-dependent assumption. The Zephyr SPI NOR binding documents several quad-enable methods, including different register locations and a case where no quad-enable bit is needed. It also exposes settings related to addressing and flash parameters. That is a reason to inspect the selected driver path rather than copy a register-write sequence from the old part.

Compare the commands and settings the product actually uses: read modes, status-register updates, protection, erase operations, power-down and recovery. A mode the application never exercises can remain outside the product’s qualification scope, but a mode used by its updater or factory programmer cannot.

Changes in capacity need particular attention to addressing and partition limits. Confirm that every software stage can reach the intended regions and that the image format, linker configuration and update layout agree. Merely reporting a larger device size does not extend those other limits automatically.

Use discoverable parameters where supported

Serial Flash Discoverable Parameters, or SFDP, provides device information in standardized tables. The Linux SPI NOR documentation explains how its driver can use those tables for generic probing. It also describes exceptions: malformed tables or features not covered by the tables can still require explicit support and fixes.

The practical conclusion is limited: successful discovery reduces some hard-coded assumptions, but it does not certify the product. Preserve the readout and driver identification in the qualification record. If firmware uses a fixed configuration instead of runtime discovery, document how that configuration was derived for each approved candidate.

Do not assume the boot code has the same capabilities as the application driver. Establish which software first accesses external flash on this product and how it selects a read mode. A firmware change that runs only after external code has loaded cannot repair an earlier boot failure.

As another concrete example, the ESP-IDF SPI Flash API documentation lists supported flash families for quad mode and distinguishes optional features. It requires checking support in both the target and the flash devices for those features. Use the documentation for the actual target and framework release; a statement about one ESP32 configuration is not a universal rule for other controllers.

Qualify the complete product path

Write the acceptance plan before accepting a replacement lot. The following is an engineering checklist to adapt to the product’s requirements, rather than a supplier qualification standard.

1. Program a fresh candidate through the production process. Include erase, programming, verification and any provisioning that the shipped product uses. Record the tool and firmware versions.
2. Exercise startup and reset paths. Check cold starts, MCU resets and the recovery paths relevant to the design. Verify that flash identification and configuration match expectations.
3. Test the actual read and write workloads. Include the regions, modes and operating conditions the product requires. Check data integrity after erase and programming, not just whether the application reaches its main screen.
4. Run the field-update process. Test a successful update, a rejected image where applicable, and recovery from deliberately interrupted updates on qualification hardware. Define the expected recoverable state in advance.
5. Review timing and power behavior. Use the product’s environmental and electrical requirements to set the test conditions. Do not invent a universal number of samples or cycles.
6. Record the release decision. Link the approved ordering codes to the board revision, software configuration and evidence. List unresolved restrictions explicitly.

An interrupted power supply and an erase-suspend command are different events. Test each only where relevant, with separate expected outcomes. A device supporting suspend does not by itself make an interrupted write or update recoverable.

Turn the result into a purchasing instruction

A passed bench experiment should become an explicit approved-alternate decision. Put the exact qualified ordering codes in the controlled BOM or approved-parts record. Specify any accompanying firmware version or assembly change. Otherwise purchasing may select a related suffix that was never evaluated, or a later build may reuse the old configuration.

If a candidate needs a board change, compare that engineering effort with the product’s remaining life and supply needs. If it needs only a driver change, the update and installed-base implications still belong in the decision. The least disruptive replacement is the one supported by the complete evidence, not necessarily the one that looks closest in a catalog.

For a supply redesign review, send the schematic, layout or package details, current and proposed ordering codes, MCU, firmware versions and production programming process. Those inputs make it possible to separate a plausible candidate from an approved substitute and define the work needed between them.