How Do You Store Data in Embedded Flash Memory?

Detailed Explanation

Almost every embedded product needs to remember something across power cycles — calibration constants, user settings, pairing keys, a data log, an event counter. The natural instinct is "just write it to flash," and that instinct collides with the physics of how flash memory actually works. Understanding three constraints up front turns non-volatile storage from a recurring source of field failures into a routine design task.

Why Flash Is Not an EEPROM

1. Writes are one-directional. Programming flash can only change erased bits (1s) to 0s. Changing any 0 back to 1 requires erasing an entire sector — typically 4 KB on SPI NOR flash, and often larger on internal MCU flash (sector sizes vary widely by part; check the reference manual).
2. Erases wear the cells. Each erase cycle degrades the sector slightly; datasheets specify endurance commonly between 10,000 cycles (much internal MCU flash) and 100,000 cycles (typical SPI NOR), after which retention is no longer guaranteed.
3. Writes and erases are slow and can stall the CPU. Sector erases take tens to hundreds of milliseconds on typical parts, and on many MCUs the core cannot fetch instructions from a flash bank that is mid-erase — a detail that surfaces as mysterious latency spikes when storage and code share a bank. Where the data lives relative to code is a memory map and linker decision, not just a driver call.

NAND flash (the technology inside SD cards, eMMC, and high-density raw NAND chips) adds two more: factory and runtime bad blocks that must be mapped around, and read/program disturb effects requiring error-correcting codes. This is why raw NAND is rarely managed by application firmware directly — SD and eMMC embed a controller that handles it internally.

The Storage Technology Menu

The pattern worth internalising: flash for data that changes occasionally, EEPROM/FRAM for data that changes constantly. A totaliser counter updated every second belongs in FRAM (or an RTC backup register), not in any flash-based store.

Wear Levelling: Spreading the Damage

Wear levelling means arranging writes so erase cycles spread across many sectors instead of hammering one. It can be as simple as a circular log (append records sequentially through a large region, erase the oldest sector only when wrapping) or as involved as the dynamic block allocation inside littlefs or an SD card's controller. The endurance arithmetic is always the same — total available erase cycles across the rotated region divided by the erase rate — and it should be run for every repeating write in the product before the storage layout is frozen. The worked example in the FAQ below shows how the same workload lasts decades or months depending purely on layout.

Filesystems: littlefs and FatFs

A filesystem earns its overhead when the data is genuinely file-shaped — variable-size records, multiple independent items, growth over time. The two embedded standards solve different problems:

• littlefs was designed for raw NOR flash on microcontrollers: every update is copy-on-write (the old data remains valid until the new version is completely committed, so power loss at any instant leaves either the old or the new state — never a corrupt one), wear levelling is built in, and RAM use is small and bounded. It is the default choice in Zephyr, Mbed, and much of the modern ecosystem — for internal product storage it should be the starting assumption. (In Zephyr-based firmware it slots in behind the standard filesystem and settings APIs.)
• FatFs implements FAT — the format PCs, cameras, and card readers understand. Use it when interoperability is the requirement: SD cards a user removes, USB mass-storage. Its weaknesses are the mirror of littlefs's strengths: FAT updates its allocation tables in place (corruption-prone on power loss without careful mount/sync discipline) and has no concept of wear — acceptable on SD/eMMC whose controller handles wear internally, hazardous on raw NOR/NAND without a translation layer.

And sometimes no filesystem is the right answer: a fixed-layout circular record log on raw sectors is simpler, faster, more endurance-predictable, and easier to make power-fail-safe than any filesystem — the standard choice for high-rate black-box logging.

Power-Fail-Safe Writes

Products lose power mid-write — batteries die, users unplug, brownouts happen. The design rule: critical data is never updated in place as a single copy. The minimal robust pattern is two copies plus validation: write the new version to the other slot (with a CRC and an incrementing sequence number), verify it, and only then consider it current; on boot, load the highest-sequence copy with a valid CRC. Key-value stores (ESP-IDF NVS, Zephyr NVS) and littlefs implement equivalent guarantees internally — one reason to use them instead of hand-rolled sector writes. Whatever the mechanism, the verification standard is empirical: a test rig that kills power randomly during sustained writes, thousands of times, and checks state on every reboot. Designs that haven't survived that test haven't demonstrated power-fail safety — they've assumed it.

Fitting Storage into the Flash Map

Data storage shares the flash with the application image and the update machinery, so the partition layout is designed once, together: bootloader, application slot(s), OTA staging area, and the data region(s) — with the data partitions deliberately excluded from what an OTA update erases, so settings survive firmware upgrades, and deliberately included in what a factory reset clears.

Design Considerations

• Run the endurance arithmetic first. Every repeating write — logs, counters, settings autosave, boot counters — gets the cycles-versus-rate calculation before the layout is frozen. The failures this prevents appear two years after shipping and cannot be fixed remotely.
• Batch and buffer writes. Accumulate log records in RAM and flush periodically (or on meaningful events) rather than per sample; on sleep-heavy designs, flush before entering deep sleep rather than on every wake. Fewer, larger writes mean fewer erases and less time stalled.
• Separate configuration from logging. Settings (small, rare writes, must never corrupt) and logs (bulk, constant writes, individual records expendable) have opposite requirements — give them separate partitions and, where budget allows, separate technologies.
• Design the factory-reset and migration story up front. What clears on factory reset, what survives OTA updates, and how version N+1 firmware reads version N's stored data are schema decisions — add a version field to every stored structure from day one.
• Plan for manufacturing. First-boot behaviour with blank flash, programming calibration data in production, and pre-loading assets are part of the storage design, not an afterthought for the production line to discover.

Storage bugs are among the most expensive class of field failures because they destroy user data and trust — Zeus Design's firmware team designs and validates non-volatile storage layers, from partition maps to power-fail test rigs, for production embedded products.

Common Mistakes

• A single settings copy updated in place. The classic design that works on the bench for months and bricks devices in the field the first time power fails mid-write. Two slots, CRC, sequence number — or a store that provides the same guarantee.
• Ignoring erase-cycle arithmetic for "small" repeating writes. A counter written once a minute to the same sector consumes a 10,000-cycle internal flash in a week. The write's size is irrelevant; the erase rate per sector is everything.
• FAT on raw NOR flash because a filesystem was needed and FAT was familiar. No wear levelling, in-place metadata updates, no power-loss safety — three field-failure mechanisms in one decision. Use littlefs for internal raw flash; reserve FAT for media a PC must read.
• Storing constantly-changing state in flash at all. Run-hour totalisers, live positions, rolling averages — these belong in FRAM, battery-backed RAM, or RTC backup registers, with flash receiving occasional checkpoints only.
• Testing power-fail safety by unplugging a few times. Corruption windows are microseconds wide; hitting them takes an automated rig cutting power at random offsets across thousands of write cycles. A design review that asks "what state results if power dies between these two lines?" for every write path is the cheap version of the same discipline.