What's changed: Initial version
2.3Non-volatile memory
Covers the two flagship non-volatile memories that retain data with power removed—NOR flash and NAND flash—and how their uses differ, EEPROM for byte-addressable rewriting, and the embedded-unavoidable write-cycle endurance limit together with wear leveling, the technique that spreads writes to mitigate it.
An embedded system must retain its firmware itself, along with settings and logs, in a form that survives power loss. But "any non-volatile memory will do" is not true—NOR flash, NAND flash, and EEPROM each excel at entirely different use cases. Furthermore, flash memory carries a physical constraint called the write-cycle endurance limit, and a design that ignores it can drastically shorten a product's service life. This section covers the two practical judgments of selecting non-volatile memory and managing its endurance.
2.3.1NOR flash versus NAND flash
- NOR flash supports byte-addressable random access, letting the CPU execute code directly by addressing it (XIP: eXecute In Place). Read speed is fast and reliability is high, but writing and erasing are slow, and its per-bit cost is high, making it unsuited to large capacities. It is used to store the bootloader and the firmware image itself.
- NAND flash is fundamentally accessed per page/block, and is unsuited to random byte access or XIP. Its per-bit cost is low, favoring large capacities, and writes are relatively fast, but its reliability is lower than NOR's, requiring bit-error management (such as an error-correcting code, ECC). It is used to store data logs and file systems.
2.3.2EEPROM and FRAM
- EEPROM is a non-volatile memory that can be individually rewritten one byte at a time. Unlike flash, it need not be erased in blocks, making it well suited to frequently updating configuration values, calibration data, and small parameters a byte at a time. Its capacity is small and its per-bit cost is high, so it is unsuited to storing large volumes of data.
- FRAM (ferroelectric RAM) is a non-volatile memory that retains information via ferroelectric polarization. Its rewrite speed is far faster than flash or EEPROM, and its write-cycle endurance limit is far higher, but its per-bit cost is high and it is unsuited to large capacities. It is considered for use cases requiring very frequent rewriting, such as frequent log updates.
Most-tested distinctions: "NOR flash = XIP-capable, highly reliable, suited to the bootloader", "NAND flash = page/block-based, large capacity, suited to data logs", and "EEPROM = byte-level rewriting, suited to small parameters". Watch for the misconception that "all flash types support XIP"—only NOR supports XIP.
A designer of an IoT sensor device is selecting non-volatile memory for three uses: (1) the bootloader and firmware image, (2) device-specific calibration parameters (a few dozen bytes, written once at the factory and rarely updated thereafter), and (3) a sensor log appended every minute, reaching several megabytes over the long term. For (1), it is desirable for the CPU to execute the code directly right after boot, and frequent rewriting does not occur, so NOR flash, which supports XIP and offers high read reliability, is appropriate. For (2), although the capacity is small, there is a requirement to rewrite individual bytes precisely, so EEPROM, which needs no block erase, is the easier choice compared to flash. For (3), the capacity is large (several megabytes) and high-frequency appends (once per minute) continue over a long period, so large-capacity, low-per-bit-cost NAND flash is suitable—but this runs into the constraint of the write-cycle endurance limit (typically on the order of thousands to tens of thousands of cycles for NAND). If the implementation simply keeps appending the log to the same physical block, only the blocks near the start of the log would be rewritten repeatedly, risking that those specific blocks hit their endurance limit (becoming bad blocks) well before the product's intended service life is reached. To avoid this, the controller or file-system layer applies wear leveling (a technique that rotates the physical blocks written to evenly, so writes do not concentrate on any one block), leveling out the rewrite count across the whole flash device and designing the product to last for its intended service life.
| Type | Access granularity | Characteristics | Typical use |
|---|---|---|---|
| NOR flash | Byte (for reads) | XIP-capable, reliable, slow write, costly | Bootloader, firmware |
| NAND flash | Page/block | Large capacity, low cost, needs ECC | Data logs, file systems |
| EEPROM | Byte (for writes) | Small capacity, costly, easy per-byte rewrite | Settings, calibration parameters |
Trap: "Flash memory has no write-cycle constraint, so it can be used without worry" is wrong—both NOR and NAND have a physical write-cycle endurance limit, and concentrating writes on specific blocks risks bad blocks partway through the product's service life, making wear leveling essential. Also wrong: "NAND flash supports direct execution via XIP just like NOR"—only NOR supports XIP; NAND allows only page/block-level access and cannot be executed directly by the CPU.
2.3.3Section summary
- NOR flash = XIP-capable and reliable, suited to the bootloader; NAND flash = page/block-based, large capacity, low cost, suited to logs
- EEPROM is a non-volatile memory suited to small parameters, individually rewritable a byte at a time
- Flash has a write-cycle endurance limit; without wear leveling to spread writes, blocks can go bad before the intended service life
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You need the CPU to execute the bootloader code directly by addressing it right after boot, and frequent rewriting will not occur. Which non-volatile memory is most suitable for this use case?
Q2. An IoT sensor device needs to store a several-megabyte sensor log, appended once per minute, over a long period. From a capacity and cost standpoint, which non-volatile memory choice is most appropriate?
Q3. An implementation appends a sensor log to NAND flash every minute, always overwriting starting from the same initial block. Blocks near the start went bad well before the product's intended service life. What is the most appropriate root cause and remedy?