NAND Flash is a type of non-volatile solid-state storage organized in pages and blocks, where cells are erased in large blocks and written in pages, making it well-suited for high-density data storage at relatively low cost per bit. Unlike NOR Flash, NAND does not support random in-place code execution and requires a controller or driver to manage addressing, wear leveling, and error correction.
In practice
NAND Flash appears in embedded systems that need megabytes to gigabytes of non-volatile storage: data loggers, cameras, consumer electronics, industrial gateways, and any design that needs to store firmware images, file systems, or bulk data. Raw NAND (parallel or serial SPI NAND) is common on cost-sensitive boards, while managed NAND variants such as eMMC and SD cards bundle an internal controller that handles the low-level complexity.
The fundamental access model differs sharply from NOR Flash or RAM. A typical raw NAND device has pages of 2 KB to 16 KB that must be written sequentially within a block, and blocks of 64 to 512 pages that must be erased before any cell in them can be reprogrammed. This page-program/block-erase asymmetry means firmware must implement or rely on a flash translation layer (FTL) or a flash-aware file system such as YAFFS2, UBIFS, or LittleFS to spread writes across blocks and avoid premature wearout.
Bit errors are an inherent characteristic of NAND Flash, and their frequency increases as the device ages and as cell geometry shrinks. Raw NAND datasheets specify a bit error rate (BER) and a required error-correcting code (ECC) strength, commonly 1-bit per 512 bytes for older SLC parts and 8-24+ bits per 1 KB for MLC/TLC devices. ECC must be applied on every read and write in raw NAND systems, whether by the MCU, SoC NAND controller, or another layer in the storage stack; many application-class SoCs (i.MX, SAMA5, RK3xxx) include a hardware NAND controller with built-in ECC engines. Microcontroller-class devices typically access NAND through SPI NAND (e.g., Winbond W25N series) where the device itself handles some ECC.
Bad blocks are factory-marked and develop over the lifetime of the device. Drivers must read and maintain a bad block table, skip defective blocks, and reallocate data to spare blocks. Ignoring bad block management is a common source of silent data corruption in production systems. Boot sequences on ARM-based SoCs that use raw NAND typically require a small first-stage bootloader (stored in on-chip ROM or a dedicated boot block) to copy a second-stage image into SDRAM before execution begins, as described in the blog post "Boot Sequence for an ARM based embedded system."
Discussed on EmbeddedRelated
Frequently asked
Why can't firmware execute directly from NAND Flash the way it can from NOR Flash?
NAND
Flash does not provide a random-access, memory-mapped interface. Data must be read out sequentially in full pages through a command interface (parallel bus or
SPI). There is no way for a CPU to fetch individual opcodes directly from a NAND address space, so code must first be copied into
RAM or executed from NOR/internal Flash.
NOR Flash, by contrast, exposes each byte on an address/
data bus, enabling XIP (execute in place).
What is the difference between SLC, MLC, and TLC NAND, and why does it matter for embedded designs?
SLC (single-level cell) stores 1 bit per cell, MLC stores 2 bits, and TLC stores 3 bits. Higher bits-per-cell increases density and lowers cost but reduces endurance (SLC: ~100,000 P/E cycles; MLC: ~3,000-10,000; TLC: ~500-3,000), increases raw bit error rates, and typically slows write speed. Industrial and high-reliability embedded designs often require SLC or industrial-grade MLC NAND to meet lifetime and temperature specifications. Consumer-grade TLC parts are rarely suitable for write-intensive embedded applications without careful FTL tuning and overprovisioning.
What file systems are commonly used with raw NAND in embedded Linux systems?
UBIFS is the most widely used file system for raw NAND on embedded Linux; it runs on top of the UBI (Unsorted Block Images) layer, which handles
wear leveling and bad block management. YAFFS2 is an older alternative with simpler implementation. JFFS2 is sometimes seen on legacy systems but has scalability issues with large NAND devices. For bare-metal or RTOS targets accessing
SPI NAND, LittleFS is a popular choice because it is designed for small
flash devices and includes wear leveling; bad block management for raw NAND typically still relies on the underlying driver or device, as illustrated in the blog post 'Getting Started With Zephyr: Saving Data To Files.'
What is eMMC, and how does it relate to raw NAND?
eMMC (embedded MultiMediaCard) is a managed NAND package: it integrates raw NAND
Flash cells together with a controller that handles
wear leveling, bad block management, and ECC internally. The host sees a simple block device interface (MMC protocol) with no need for an FTL in software. This simplifies firmware development at the cost of less control over timing and write behavior. eMMC is common on application-class SoCs (i.MX6, AM335x, Allwinner A-series) where a Linux block driver is already available.
How do I know how much ECC my NAND device requires?
The datasheet will specify the required ECC strength, usually expressed as 'N bits correctable per M bytes' (for example, '4-bit ECC per 512 bytes' or '8-bit ECC per 1 KB'). Older SLC devices often require only 1-bit ECC per 512 bytes, achievable with a Hamming code. MLC and TLC devices typically require BCH codes capable of correcting 8 to 24 or more bit errors per 1 KB. Using weaker ECC than specified by the datasheet will result in uncorrectable errors as the device ages, causing silent data corruption or read failures.
Differentiators vs similar concepts
NAND
Flash is frequently contrasted with
NOR Flash. NOR Flash provides a memory-mapped interface that supports XIP (execute in place), making it the typical choice for storing and directly executing firmware code on microcontrollers; it offers faster random reads but lower density and higher cost per bit than NAND. NAND Flash offers much higher density and lower cost per bit, sequential page-based access, and is better suited for bulk data storage, file systems, and firmware images that will be copied to
RAM before execution. NAND also requires ECC and bad block management that NOR does not. eMMC and SD cards are managed NAND variants that hide these complexities behind a block device interface, whereas raw NAND exposes them directly to the system designer.
