When a part has 128 KB of program memory, the EEPROM beside it looks like an afterthought — a few kilobytes at most. In practice it is the part of the device that carries the identity: serial numbers, calibration constants, usage counters, per-unit keys. The flash is the same in every unit; the EEPROM is what makes each unit distinct.

It is also the array with the most unusual rules, because it is addressed separately, written slowly, and its survival through an erase depends on a single fuse.

A different address space

EEPROM is not mapped into the program address space. It has its own instructions, its own control register, and its own read and write paths:

The write-time row is the one that catches people out. Writing a byte takes roughly the same time as writing a whole flash page, which means a firmware that logs to EEPROM frequently is spending most of its time waiting. It also means a device that loses power mid-write can leave a byte in an indeterminate state — a real phenomenon, visible in dumps as isolated anomalies in an otherwise orderly table.

What a reading of the EEPROM tells you

Three categories of content appear again and again:

Identity. A serial number, a build date, a hardware revision code. Short, structured, and immediately useful because it dates the device and often reveals which firmware build it shipped with.

Calibration. Offsets and gains measured per unit at the factory. This is the most valuable category for anyone trying to reproduce behaviour, because these values are not in the firmware and cannot be derived from it.

State. Counters, flags, a last-known-good record. Useful for understanding what the device has been through, and occasionally for understanding why it failed.

A blank EEPROM in a device that should have one of these is a strong signal: the part was erased, or the fuse allowed the erase to take it, or the device was never production-calibrated in the first place.

The fuse that decides survival

Chip erase clears the flash and the lock bits together. Whether it also clears the EEPROM is decided by one fuse, active-low like the rest: programmed means the EEPROM is preserved.

This is set for operational reasons, not defensive ones. Products that update firmware in the field want calibration to survive the update. That decision, made for convenience, is what makes the EEPROM recoverable from a locked device: erase to clear the locks, and the EEPROM is still there.

When the fuse is not set, the erase produces a clean blank part and nothing else. Knowing that early is worth a great deal, because it converts an open-ended investigation into a closed one.

Reading it correctly

Two practical notes.

The read is byte-addressed and does not need page alignment, so a straightforward sequential read works. But the array is small and the interface overhead dominates, which means a read that seems slow is normal rather than faulty.

The read is gated by the lock bits exactly as the flash is. In mode 2 or 3 the EEPROM read command is refused along with the flash read command. So the sequence on a locked part is erase first, read second — and the only reason that sequence yields anything is the fuse above.

Why it matters more than the code, sometimes

Consider a product built around this part that measures something: a sensor interface, a power meter, an instrument. The firmware implements the algorithm. The EEPROM holds the constants that make the algorithm correct for that specific unit — the offset of this sensor, the gain of this amplifier, the scale factor of this shunt.

Reproducing such a product from a flash image alone produces a device that measures consistently wrong. Adding the EEPROM constants makes it measure correctly. The flash is the logic; the EEPROM is the truth about the physical unit.

That is why a recovery that returns only the program is often described as incomplete, and it is why the fuse read belongs at the very start of the process rather than at the end.

Related notes

• ATmega1280PV and the three-byte counter — the address-space question on the same family.
• ATmega2561V and EESAVE — the same fuse on the largest member.
• ATmega32PA and the EEPROM that outlives the flash — the mechanism explained from first principles.

FAQ

How large is the EEPROM on this part? It is a few kilobytes, small relative to the flash and large relative to a serial number and a calibration table.

Can the EEPROM be read without erasing? Only if the lock bits permit verification. In mode 2 or 3 the read is refused, and the erase that opens the door destroys the flash.

Does writing EEPROM wear out the flash? No, they are separate arrays with separate endurance figures. EEPROM is rated for far more cycles than flash.

Can EEPROM contents be transplanted to another part? Yes, mechanically. Whether it works depends on whether the values are per-unit, which they usually are.

Conclusion

On a large-flash part the EEPROM is small, separate, and disproportionately informative. Its addressing, its endurance, and its write timing are all different from flash, and its survival through an erase depends on one fuse that was set for operational convenience. Reading that fuse first is what makes the rest of the plan either short or impossible.

Comments are closed.