8-bit MCUs with EEPROM built in

Built-in EEPROM is a small block of non-volatile memory on the microcontroller die. It survives a power cycle, and the firmware can rewrite it in the field. A handful of bytes live there across every power-off: a thermostat’s set point, a meter’s running total, a product’s calibration constants and serial number. The array is small, it writes a byte at a time, and each cell takes a fixed number of writes before it wears.

What built-in EEPROM is for

Built-in EEPROM holds the data a product changes and keeps. A user sets a thermostat to a temperature, and the setting stays through the next power cut. A remote learns a code. A scale tares to zero. Each of these is a few bytes the firmware writes once in a while and reads at every startup. The EEPROM is where they sit when the power is off. The data is small: a byte for a mode, a byte for a brightness level, a word for a set point. A whole menu of options fits in a few dozen bytes. The firmware loads them once at boot, and the product comes up the way the user left it. After a reset the firmware reads the settings back from the EEPROM, and the product looks unchanged to the user.

Calibration constants live there too. A factory measures each unit and writes its offsets into the EEPROM at the end of the line. The firmware reads those constants at boot and corrects its readings with them. The constants are written one time and read at every startup for the life of the product. A serial product carries its own numbers in its own EEPROM. A typical set is an ADC gain and offset, an oscillator trim value, and a sensor linearization point or two. Each unit off the line gets its own numbers, measured and written at final test. A reading corrected with these constants is accurate from the first power-on.

Counters and logs use the EEPROM as well. A printer counts pages. An appliance counts run hours toward a service interval. A device logs its last fault code for a technician to read. Each write records a number that has to outlive the power. The count climbs across years and power cycles, held in the same few bytes. An odometer counts kilometers. A battery gauge counts charge cycles. A coffee machine counts shots toward a descale reminder. The number rides through the wall switch and the unplugged night, and it reads back at the next power-on right where it left off.

A product keeps its identity in the EEPROM. A serial number goes in at manufacture. A network device keeps its address and its pairing. A machine keeps its last state to resume after a power blip. These bytes turn a fresh boot into a continuation of where the product left off. The EEPROM is the memory of the product across its whole life. A smart bulb keeps its network key and its room assignment. A power tool keeps its trigger calibration. A controller keeps a fault history a service tool reads later. Without the EEPROM, each of these would start blank at every power-on.

Where the bytes are kept

On-chip non-volatile storage comes in a few forms. A dedicated EEPROM block changes a single byte without disturbing the rest, separate from the program flash. A part without that block emulates EEPROM in a reserved area of its flash, where a write touches a whole page. A newer part can carry a high-endurance flash block in place of the old EEPROM, rated near the same write count. The table below sets the forms side by side. The dedicated block is a small array with its own controller, built for many small writes. The emulated form borrows program flash and runs a library that erases and rewrites a page to change a byte. The high-endurance flash block sits between them, a flash region the maker rates for the write count an EEPROM job needs.

Each form reads the same way, by address. The write path is where the three differ. The datasheet names the form a part carries. A design that ports between parts checks this first, since the form decides the driver code and the endurance the firmware can count on.

External serial EEPROM and FRAM, on an I2C or SPI bus, carry kilobytes to megabytes for a design that outgrows the on-chip array; choosing between those external chips is a separate question. The on-chip block stays the first stop for the small settings a product reads at every boot. A design reaches off-chip when the data no longer fits in the few hundred bytes on the die. FRAM writes at bus speed with no write delay and takes far more write cycles than an EEPROM, which suits a log that updates constantly. A serial EEPROM adds a large capacity at a low price. The on-chip block wins on the parts count, since it adds no second chip and no bus. For a few bytes of settings, the on-chip block is the whole answer. The external chips come in only when the data runs to kilobytes.

How the on-chip EEPROM works

An EEPROM cell holds a bit on a floating gate, the same idea as flash. A write moves charge onto or off the gate to set the bit. The block writes and erases a byte at a time, so the firmware changes one setting and leaves the rest in place. Reading a byte is quick and leaves the cell unchanged. Each write to a cell takes a few milliseconds and counts against its life. The floating gate traps electrons behind an insulator, and the charge holds with no power applied. A read senses the charge and leaves it in place. A write forces charge through the insulator. That stress wears the cell over many cycles. The wear is gradual, so a cell weakens well before it fails outright, and a checksum gives early warning of a cell on its way down.

A byte write takes a few milliseconds, far longer than a write to RAM. The part raises a ready flag when the write finishes. The firmware waits for that flag before it starts the next byte. A burst of writes runs at the speed of the EEPROM. A design that saves a block of data plans for the milliseconds it takes. A write of one byte runs in a few milliseconds, so saving a hundred bytes takes a noticeable fraction of a second. The firmware can run other work while the write completes and check the flag later. A save scheduled at a quiet moment hides the delay from the user. A few hundred bytes, written one at a time, can run for the better part of a second. A settings save waits for a pause in the work, and the ready flag lets the firmware overlap the wait with other tasks.

Each cell takes a fixed number of writes before it wears out. A dedicated EEPROM cell is good for around a hundred thousand write cycles. The number is per cell. A byte written a hundred thousand times reaches its limit. The cell beside it, written rarely, stays good for far longer. The maker states the endurance in the datasheet, and a design counts its writes against that number over the product’s life. A hundred thousand cycles covers a setting changed a few times a day for decades. The same hundred thousand covers a counter saved every second for only about a day. Whether that number is plenty or nothing depends on the write rate. A setting changed at every user action uses a handful of cycles a day, far inside the limit. A per-second log needs batching or wear-leveling to stay inside it.

The data holds for years with no power on the chip. A written cell keeps its charge for a retention time the datasheet gives, often decades at room temperature. Heat shortens that time. A product that sits in a hot place reads its EEPROM less surely after many years. For the life of an ordinary product, the data stays where it was written. Retention falls as the temperature rises, the same physics that governs flash. A part rated for decades at twenty-five degrees holds for less at eighty. A product in an engine bay or a hot enclosure plans its retention against the temperature it sees. A periodic rewrite refreshes the charge on data that has to last.

A write needs stable power to finish. A write cut short by a power loss can leave a byte half-written and wrong. A brown-out detector on the part holds off a write when the supply sags below a safe level. The firmware checks the supply, or leans on the brown-out circuit, before it commits a write. A capacitor that holds the rail up for a few milliseconds lets a write finish after the power is cut. A half-written byte reads back as neither the old value nor the new one. A checksum on the data catches that case at the next boot. The safest designs write at a known-good supply and verify the byte after the write returns. A board with a large bulk capacitor and an early power-fail signal gets a clean window to finish a write as the supply falls. The firmware catches the power-fail interrupt, writes the critical bytes, and lets the capacitor hold the rail until the write returns.

The endurance limit

The endurance number sets a hard rule for how often a byte changes. A hundred thousand writes sounds like plenty until a design writes the same byte on a schedule. A counter that saves to one byte every second wears it out in about a day. A value stored on every loop dies in minutes. A design that respects the limit writes a cell only when the data changes, and it spreads frequent writes across many cells. The endurance limit is a budget, spent one write at a time. A hundred thousand divided by one write a second is about twenty-eight hours. A design that saves often reaches for wear-leveling or for FRAM, where the cycle count is far higher. The arithmetic is simple. It is the first check to run on any value the firmware saves on a schedule. A value that changes many times a second belongs in RAM, written to the EEPROM once at shutdown or at a long interval. The design keeps the live value in RAM and commits a snapshot, which turns thousands of writes into one.

Using the EEPROM well

Two habits keep the EEPROM alive for the product’s life. The firmware reads a byte before it writes, and skips the write when the value has not changed. This write-on-change rule cuts the writes down to the times the data changes. Wear-leveling spreads a frequently-written value across a ring of cells, so no single cell takes every write. A counter rotated across a hundred cells lasts a hundred times as long. A ring buffer writes each new value to the next cell in turn and marks it with a sequence number. The firmware finds the newest entry at boot by the highest sequence number. The wear spreads evenly across the ring. The array lasts as long as the ring is wide. A design sizes the ring from the write rate and the endurance. A value saved once a minute, across a ring of fifty cells, outlasts the product on a hundred-thousand-cycle part. A stored value carries a way to check itself. The firmware writes a checksum or a CRC beside the data and verifies it on read. A failed check tells the firmware the byte is corrupt. The firmware then falls back to a safe default. A second copy of the data, written to a different place, gives the firmware a spare to read when the first one fails. A CRC catches a multi-bit error that a simple checksum can miss. A version byte alongside the data lets the firmware tell an old layout from a new one after a firmware update. These few extra bytes turn a silent corruption into a clean fallback. A magic number at the start of the block tells the firmware the EEPROM has been written at least once. A blank chip from the factory falls back to defaults on the first boot and writes the defaults and the magic number together.

The write happens where the power and the timing are safe. The firmware commits a write with the supply known good, away from a moment the power might drop. A library hides the byte-by-byte access behind a simple call: AVR parts read and write the EEPROM through the routines in AVR-libc, documented on its EEPROM page. The firmware reads the whole block at boot into RAM, works from RAM, and writes back only the bytes that changed. The EEPROM sees a write only when a setting changes. Working from a RAM shadow keeps the application code fast and simple, and it batches the writes. A single save at the end of a settings change writes only the bytes that moved. The EEPROM stays idle through all the reads in between.

Which 8-bit parts have it

The classic 8-bit families ship with a dedicated EEPROM block. An AVR part, the ATmega328P among them, carries a few hundred bytes to a couple of kilobytes of EEPROM beside its flash. A PIC16 or a PIC18 carries a data EEPROM of a few hundred bytes. An STM8 carries a data EEPROM block as well. A datasheet lists the size and the endurance for the exact part, and a design that needs on-chip non-volatile storage checks that line first. The ATmega328P carries a kilobyte of EEPROM, enough for a deep settings menu and a calibration table. A small ATtiny carries tens to a few hundred bytes. A PIC16F carries a couple hundred bytes of data EEPROM. The size on the datasheet sets how much a design keeps on-chip.

The classic Arduino boards run an ATmega328P, so a generation of hobby and product code reads and writes that kilobyte through a known library. A PIC project reaches its data EEPROM through the special function registers the datasheet lists. Even a small ATtiny carries enough EEPROM for a serial number and a few flags, so the smallest design keeps a little state across a power cycle.

A newer part can replace the dedicated block with a flash-based store. Some recent PIC parts offer a high-endurance flash block rated near the old EEPROM’s hundred thousand cycles. Other parts emulate EEPROM in ordinary flash through a library, with a page-sized write and a lower endurance. A design reads the datasheet to learn which form a part carries, since the part number alone does not say. The form sets the endurance, the write granularity, and the code that drives it. High-endurance flash gives the byte-level feel of EEPROM on a part built without a dedicated block. Flash emulation trades some program space and a page erase for the same result on a part that has neither. A design that leans on on-chip storage reads the memory section of the datasheet before it commits to a part. A migration from an older part to a newer one reads this section closely, since a part that dropped its dedicated EEPROM needs different code to reach its store. The behavior a design relied on can move into a library call.