Microcontroller Nonvolatile Memory & Programming
Flash, EEPROM, fuse/configuration state, lock bits, boot sections, and debug/programming ports have different write granularities and protection rules. Programming is a power-sensitive state transition with explicit authority, not an ordinary memory store.
Microcontroller nonvolatile state is plural. Program flash, data EEPROM, user/configuration words, fuse-like options, calibration rows, lock bits, and debug/programming security can have different erase units, write sequences, lifetimes, and access paths.
Storage classes #
| State | Typical role | Important boundary |
|---|---|---|
| Program flash | Executable code and constants | Erase by page/sector; execution and self-write rules |
| EEPROM/data flash | Small persistent settings and counters | Endurance, atomicity, wear, and power-loss behavior |
| Fuse/configuration | Clock, reset, boot, debug, or memory policy | May take effect only after reset and can disable the current access path |
| Lock/security bits | Restrict read, write, self-program, or debug | Protection may be one-way until chip erase |
| Calibration/signature | Factory trim and device identity | Often read-only or accessed through a special address path |
“Nonvolatile” means the state survives power removal within specified retention conditions. It does not mean infinite writes, atomic multi-byte updates, or immunity to an interrupted program pulse.
Erase before program #
Flash cells normally program in one logical direction and require an erase operation to restore the other. The erase granularity is larger than a byte, so changing one field can require:
- read or reconstruct the whole erase unit;
- modify the intended data in RAM;
- erase the page/sector;
- program words or a page buffer;
- wait for completion;
- verify contents and protection state.
The exact device may provide combined erase/write modes, temporary page buffers, ready interrupts, or read-while-write partitions. Those are not portable assumptions.
Self-programming and boot partitions #
A bootloader is privileged firmware that can receive and validate an image, erase/program application flash, and transfer control. Its safe design separates four states:
- candidate bytes have arrived but are not trusted or complete;
- verified image passes length, compatibility, integrity, and authenticity policy;
- installed flash has been programmed and read back correctly;
- active boot metadata selects the image for execution.
Activation should be the smallest recoverable state change. If power fails during receive or programming, the boot path must still identify a valid image or enter a deliberate recovery mode. A CRC detects accidental corruption; it does not authenticate who supplied the image.
EEPROM records need a commit protocol #
Suppose firmware stores a 32-bit counter and configuration. A power loss between byte writes can create a mixture that passes no obvious validity test. A durable record can include version, sequence number, payload length, payload, integrity check, and a commit marker written last.
With two or more slots:
- find the newest fully valid record;
- write the next record into another erased slot;
- verify payload and integrity;
- write or otherwise establish the commit state;
- retire old records only after a replacement is valid.
Wear leveling rotates updates across cells. It cannot remove the need for power-loss atomicity or an endurance budget based on the real update rate and worst-case retry behavior.
Programming interfaces #
In-system programming, JTAG, debug-wire-like paths, high-voltage recovery, bootloaders, and vendor-specific two-wire interfaces can all reach nonvolatile state, but with different authority and pin ownership. Board design must preserve voltage levels, reset control, clock requirements, shared-pin isolation, and tool access.
Production programming is a verifiable transaction:
- identify exact device and revision;
- establish supply, reset, and interface conditions;
- erase only the authorized regions;
- program image and configuration from a versioned artifact;
- read back or use the documented verify operation;
- apply protection in the correct final order;
- reset and prove the intended boot/runtime path;
- record device identity, artifact digest, configuration, and result.
Endurance, retention, and temperature #
Endurance is a statistical guarantee under specified voltage and temperature. Retention can decrease after many cycles and at high temperature. Writes outside the allowed supply range can corrupt the target or neighboring state.
For frequently changing data, derive writes per cell from the update policy. A counter written once per second reaches 100,000 writes in under 28 hours if every update hits one cell. Buffering, checkpoint intervals, rotating records, and event aggregation are architectural requirements, not later optimizations.
Failure evidence #
| Symptom | Inspect |
|---|---|
| Code verifies but will not boot | reset vector/boot selection, fuses, address placement, startup clock |
| Programming fails intermittently | supply droop, reset, interface clock, busy sequencing, shared pins |
| Settings revert after outage | commit ordering, write completion, brown-out, invalid-record policy |
| Device becomes inaccessible | clock/debug/programming configuration, lock state, recovery interface |
| Update bricks after power loss | active-image metadata, bootloader protection, atomic activation, recovery path |
Archive the exact device manual and programming revision with the deployed artifact. A family tutorial cannot define these irreversible boundaries.