NOR Flash is a non-volatile solid-state memory technology where individual words or bytes can be read randomly at full bus speed, and where erase operations work on larger sectors. Unlike NAND Flash, NOR Flash supports execute-in-place (XIP), allowing a CPU to fetch and run code directly from the device without first copying it to RAM.
In practice
NOR Flash is a widely used storage medium for program code in microcontroller-based systems. On most Cortex-M and other MCU families, the internal Flash (e.g., STM32's up to 2 MB of on-chip Flash, or the nRF52840's 1 MB) is NOR-type, mapped into the CPU's address space so the core can fetch instructions without a separate copy step, though this typically requires correct wait-state, cache, or prefetch configuration and may involve boot remap steps depending on the device. External NOR Flash (e.g., Winbond W25Q series, ISSI IS25LP series) connected over SPI or QSPI is used when on-chip storage is insufficient, though XIP over SPI typically requires a memory-mapped cache controller or special peripheral support (such as STM32's OCTOSPI or the RP2040's XIP cache) to be practical for code execution.
Erase granularity is a key constraint in practice. NOR sectors are often 4 KB, 32 KB, or 64 KB, though sector sizes vary widely across device families and densities, and some parts support smaller sub-sectors or hybrid erase layouts. A sector must be erased before its cells can be reprogrammed. Erase cycles are slow (often 30 ms to several seconds per sector depending on size and device) and NOR Flash endurance is typically in the range of 10,000 to 100,000 erase cycles per sector, though actual ratings vary across parts, temperatures, and product classes. Firmware update strategies and file systems must account for both constraints through wear leveling or careful write scheduling.
Bootloader and firmware update designs frequently rely on NOR Flash layout decisions made early in a project. The "Boot Sequence for an ARM based embedded system" post illustrates how the processor reset vector points into Flash, making the physical Flash map a hard dependency of the boot chain. Partitioning Flash into bootloader, application, and OTA staging regions requires balancing sector boundaries, erase granularity, and protection features (many devices offer sector-level write-protect registers).
A common pitfall is assuming reads are free. On devices that execute directly from internal NOR Flash without wait-state tuning, high clock frequencies can stall the CPU waiting for Flash. Many MCUs include a Flash accelerator, prefetch buffer, cache, or similar mechanism (e.g., STM32's ART Accelerator, Kinetis's Flash Cache) to mitigate this, though the specific feature varies by vendor and core family; failing to configure wait states and any such accelerator or cache correctly for the selected core clock is a frequent cause of unexpected performance degradation or hard faults.
Discussed on EmbeddedRelated
Frequently asked
What is the difference between NOR Flash and NAND Flash?
NOR
Flash is organized to allow random byte- or word-level reads and supports XIP, making it practical for direct code execution.
NAND Flash uses a page- and block-oriented architecture that gives higher density and lower cost per bit, but reads are page-based and the memory is not memory-mapped in the way NOR is, making direct code execution impractical without additional hardware. A flash translation layer is commonly used on top of NAND for storage use cases to handle block management and
wear leveling, but it is not what prevents code execution -- that is primarily an interface and addressing constraint. NOR is the standard for code storage and boot ROMs in most
MCU designs; NAND is used for large data storage where density matters more than random access.
Can I execute code directly from external SPI NOR Flash?
It depends on the
MCU. Some microcontrollers (RP2040, STM32H7 via OCTOSPI, ESP32 via its
cache controller) include hardware to memory-map an external
SPI or
QSPI NOR device and execute code from it using an on-chip XIP cache. On MCUs without such a peripheral, code stored on an external SPI
Flash must be copied to
RAM before execution, a pattern commonly called 'load-and-go' or 'shadow to RAM'.
How do I handle Flash wear in a firmware update system?
Keep write and erase counts low by writing sequentially where possible, avoiding repeated small updates to the same sector. For logging or frequently-updated state (e.g., counters, configuration), use a simple append-only or circular scheme across multiple sectors so erase cycles spread across the
Flash. Full
wear-leveling file systems (LittleFS, SPIFFS) automate this for data regions. OTA update staging regions typically see few erase cycles over a product lifetime and usually do not require active wear leveling.
Why do I get hard faults or incorrect behavior after increasing my MCU's clock frequency?
NOR
Flash access time is fixed; as the CPU clock rises, more wait states are required for the Flash to return valid data. On STM32 devices, for example, running at 80 MHz or above without setting the correct FLASH_ACR wait-state bits will cause the CPU to read invalid instruction data. Always configure Flash wait states (and enable any prefetch buffer or
cache) before switching to a higher
PLL frequency, as described in the device reference manual.
What endurance and retention should I expect from NOR Flash?
NOR
Flash endurance ratings vary substantially across parts, temperatures, and product classes, but many commodity devices (internal
MCU Flash or external
SPI NOR) are rated in the range of 10,000 to 100,000 program/erase cycles per sector. Data retention is commonly specified at 10 to 20 years at room temperature. Endurance degrades at elevated temperatures and with increasing cycle count. High-reliability variants (e.g., automotive-grade parts from Infineon, Renesas, or Microchip) may specify higher endurance or wider temperature ranges, but these are application-specific and should be confirmed against the datasheet.
Differentiators vs similar concepts
NOR
Flash is frequently confused with
NAND Flash. The core distinction is array organization and interface: NOR Flash supports random-access reads and XIP at the cost of lower density. NAND Flash is page- and block-oriented, enabling much higher density and lower cost per bit but making direct code execution impractical without additional hardware, primarily because it is not memory-mapped in the way NOR is (rather than solely because of FTL requirements -- an FTL is used for block management and
wear leveling in storage use cases). NOR Flash is also sometimes confused with ROM or OTP memory; unlike those, NOR Flash is electrically erasable and re-programmable within its rated cycle count.
