Storage and Filesystems

Embedded storage must survive limited erase cycles, unexpected power loss, and corrupted data. Flash is not a tiny hard drive; firmware must respect erase blocks, program rules, wear, and integrity checks.

Learning Objectives

By the end of this lesson, you should be able to explain flash erase/program behavior, design simple persistent records, plan wear leveling, choose when to use a filesystem, and protect data against power failure.

Flash Basics

Read: byte or word access, usually fast.
Program: word, phrase, or page access; usually changes bits from 1 to 0.
Erase: sector or block access; slow and wear-limited.

Erase endurance may be 10k to 100k cycles depending on technology and temperature.

Persistent Record Pattern

A robust configuration record includes magic, version, length, sequence, payload, and CRC.

magic
version
length
sequence
payload
crc32

On boot, scan records, validate CRC, choose the newest sequence, and fall back to defaults if no valid record exists.

Wear Leveling

If a device writes settings once per minute, writes per year are:
$$
60 \times 24 \times 365 = 525{,}600
$$
A single sector rated for 10k erases would fail quickly. Spread records across multiple slots or sectors.
$$
cycles_{sector}=\frac{writes}{number_of_slots}
$$

Power-Fail Safety

flowchart LR OLD[Old valid record] --> WRITE[Write new record] WRITE --> CRC[Write CRC and commit marker] CRC --> VERIFY[Read back verify] VERIFY --> NEW[New valid record]

Never erase the only valid copy before a replacement is confirmed.

Filesystems

Use a filesystem when files, directories, external tools, or large logs are needed. Use raw records when data is small and structured. Embedded filesystems such as littlefs are designed for power-fail resilience and wear leveling on flash.

Worked Example: Calibration Storage

typedef struct {
    uint32_t magic;
    uint16_t version;
    int32_t offset_uV;
    int32_t gain_ppm;
    uint32_t sequence;
    uint32_t crc32;
} calib_record_t;

Keep a schema version so future firmware can migrate old records.

Common Mistakes

Rewriting flash on every loop iteration.
No CRC or magic number.
Erasing old data before new data is committed.
Assuming EEPROM and flash have unlimited endurance.
Ignoring alignment and cache rules for internal flash programming.

Summary

Embedded storage design is about endurance and integrity. Use records, versions, CRCs, sequence numbers, wear leveling, and power-fail-safe update order. Choose a filesystem only when its features justify the footprint.

Mind Map

mindmap root((Embedded Storage)) Core concept Flash erases in blocks Records need integrity Power can fail anytime Applications Calibration Settings Event logs Firmware update Calculations Writes per year Erase cycles per sector Record length CRC coverage Design rules Validate magic CRC Version records Commit last Wear level writes Practical checks Power cut test Full flash test Migration test Endurance estimate Common mistakes No CRC Single hot sector Erase valid copy first Unlimited write assumption