NOR Flash vs NAND Flash: Choosing the Right Non-Volatile Memory

Why the choice shapes the whole design #

Every embedded and edge system needs non-volatile memory to hold the code that runs at power-up and, often, the data it collects. The two dominant technologies — NOR Flash and NAND Flash — share the "Flash" name but behave very differently. Pick the wrong one and you get a board that will not boot, a bill of materials that costs more than it should, or storage that degrades under real field conditions.

The decision is not "which is better." It is "which access model matches the workload." This guide walks through the architectural difference, the dimensions that actually drive selection, and the application fits that settle the choice.

Two architectures, two access models #

NOR Flash is built so the host can read any byte directly through a memory-mapped bus. That makes it random-accessible and, crucially, able to execute code in place (XIP) — the CPU fetches instructions straight from the device. Reads are fast and uniform; writes and erases are comparatively slow because erase blocks are relatively large (commonly 64–256 KB) and the technology is optimised for read stability, not write throughput. Serial NOR (SPI, QSPI, Octal/OSPI) now dominates boot and firmware roles at densities up to about 2 Gb.

NAND Flash is organised into pages and blocks and is read or written sequentially. It is not memory-mappable and cannot execute code in place; it needs a controller or software stack to manage bad blocks, wear levelling and error correction. In return it reaches far higher densities — single devices span multiple gigabits up to terabits — at a much lower cost per bit. The program/erase throughput at volume is also far higher than NOR.

The single sentence that captures it: NOR is for reading code, NAND is for storing data. Most systems that need both use one of each.

The dimensions that decide the selection #

Matching the memory to the application #

• Boot code and firmware that executes: choose NOR. Almost every MCU or SoC

fetches its first instructions from NOR — either internal die flash or an external QSPI device. The random-access and XIP behaviour is exactly what a reset vector needs.

• Read-mostly configuration and calibration data: NOR again. Infrequent

writes and frequent reads are its comfort zone.

• OS images, large firmware, Linux root file systems: choose NAND. The

density and cost-per-bit make NOR impractical once you are shipping tens or hundreds of megabytes.

• Data logging, event recording, black-box buffers: NAND. These are

sequential, high-write-volume workloads where NAND's erase/write throughput and density win.

• Field firmware updates (FOTA): often a dual-bank NOR layout, or a NOR +

NAND combination — NOR holds the active and fallback images, NAND holds the larger update payload.

Serial NOR in practice #

For boot and firmware, serial NOR is the workhorse. Families such as Winbond's W25Q and GigaDevice's GD25 cover 1 Mb to 2 Gb in SOIC, WSON and USON packages, on 1.8 V or 3.3 V rails, with QSPI for fast XIP and Octal/OSPI for higher instruction throughput. A representative 128 Mbit part like W25Q128JVSIQ or GD25Q128ESIGR is enough to hold a substantial bootloader and application image for many Cortex-M and FPGA-configuration flows.

NAND in practice: raw versus managed #

Raw NAND (ONFI-compatible parallel or serial NAND) is cheap and flexible but demands an FTL or controller: bad-block tables, wear levelling and an ECC engine. Managed NAND — eMMC and UFS — hides all of that behind a standard interface and is usually the lower-risk choice for teams that do not want to own a flash-translation layer.

Within NAND, cell type matters: SLC is the most reliable and endurance-friendly (preferred for industrial and automotive logging), MLC trades endurance for density, and TLC pushes density and cost-per-bit to the extreme at the expense of write life. Pseudo-SLC (pSLC) is a common industrial compromise.

Interface and controller cost #

The memory price is only part of the bill. NOR over SPI needs almost no controller logic — the MCU's built-in QSPI peripheral is usually enough. NAND needs an ECC engine and either a software stack (for raw NAND) or an eMMC/UFS controller (for managed NAND). That difference shows up in firmware complexity, validation time and, for raw NAND, long-term field reliability. For a small firmware-only design, NOR is often the cheaper *system* even when the raw device costs more.

A practical selection checklist #

• Does the code need to execute in place at boot? → NOR.
• Is the data mostly sequential and larger than ~512 Mb? → NAND.
• Is the environment harsh (wide temperature, vibration, long service life)? →

NOR or SLC/pSLC NAND, with automotive-grade qualification if required.

• Do you need both boot and bulk storage? → QSPI NOR for boot plus managed NAND

for data, or internal MCU flash plus external NAND.

• Is firmware simplicity a priority over raw device cost? → lean toward

managed NAND or NOR.

What to confirm before you buy #

When sourcing either technology, do not stop at the family name. For serial NOR, the density, voltage (1.8 V vs 3.3 V), package (SOIC vs WSON/USON), speed grade and automotive qualification (AEC-Q100) all live in the suffix — a W25Q128 "JVSIQ" and a "JVSIM" differ in package and temperature grade. For NAND, confirm the cell type (SLC/MLC/TLC), the managed-vs-raw interface, the ECC requirement and the endurance rating for your write profile. For long-life industrial and automotive builds, traceability and date code still matter as much as the headline density.

Conclusion #

Choose NOR Flash when the workload is code and configuration that must be read randomly and executed in place — bootloaders, firmware and calibration data. Choose NAND Flash when you need high density and cost-effective sequential storage for OS images and logged data. The two are not competitors so much as complements, and many production designs use both. Settle the interface, density, endurance and qualification from the actual read/write pattern of your application, not from a generic "Flash" line item, and the rest of the storage subsystem tends to fall into place.