Eight kilobytes of persistent storage is the kind of figure that makes an engineer think of one specific thing, and on most microcontrollers that thing is an EEPROM: byte addressable, byte writable, a hundred thousand cycles, no erase step.

This part does not have one. It has a second flash array, and calling it «data flash» is accurate in a way that the request «extract the EEPROM» is not. The difference is not terminology. It changes what the firmware must do, what can be lost, and how a recovery has to read it.

Two arrays behind one controller

The code flash and the data flash are separate address ranges served by the same programming interface. They are not the same array divided in two; they are distinct structures with distinct roles, and on this part the split is fixed at 128 KB or 256 KB of code and 8 KB of data depending on the ordering code.

The third and fourth rows are the ones that separate this from an EEPROM. Reading either array is an ordinary load from an address. Writing either array is an operation with a command sequence, a block granularity and an erase step.

Why the EEPROM comparison fails

The fifth row is the one with consequences for a recovery. A design that treats the data array as a settings page and rewrites one field when a user changes it is performing, underneath, an erase and a rewrite of an entire block. If the power fails during that operation, the block is not left with the old value and not left with the new one. It is left erased, or partly programmed, and everything that shared the block is gone.

That is why serious designs on this class of part do not write directly. They either keep a shadow copy in RAM and commit rarely, or they use a scheme that never overwrites the only copy of anything.

What the firmware does instead

Three patterns appear again and again, and recognising which one a product uses is one of the more useful outcomes of reading its image.

A rotating log. Records of fixed length written in sequence through the array, each with a sequence number or timestamp, wrapping to the start when the array is full. The newest record is authoritative. Power loss costs the record being written and nothing else.

Two-block ping-pong. Two blocks hold alternate copies. One is always complete. A commit writes the inactive block, verifies it, and then flips a pointer. Power loss costs one update, never the last good state.

A block-aligned settings image. The whole block is a structure with a header, a version, and a checksum. Every change rewrites it entirely. Simple, robust against corruption, and hard on endurance if changes are frequent.

Identifying the pattern from a dump takes minutes and answers a question customers ask constantly: what happens to my calibration if the unit loses power during a save.

Reading it, and why it is a separate file

The data array is memory-mapped at its own address, which makes reading it trivial and merging it into the code image wrong. The two arrays live at different addresses, are programmed by different commands, and are restored by different operations. A merged file cannot be written back correctly by anything.

The deliverable therefore has two files, and the report should state the base address of each. That single line prevents the most common downstream mistake, which is a customer’s programming fixture writing the data image at address zero.

What the data array usually holds

On a part this small the eight kilobytes are almost never a general-purpose store. They are one of a handful of things, and the contents are usually recognisable at a glance:

• a calibration set with a header and a checksum, occupying a fraction of the array;
• a usage log, regular in structure, with a monotonically increasing field;
• a serial number and a manufacturing record, written once at production;
• a copy of settings that also exist in flash, kept as a fallback.

The third item is worth looking for specifically. Where a serial number exists it is often the piece of information the customer actually needs, because it ties the unit to a production record, and it is not recoverable from anywhere else once the part is gone.

What the deliverable contains

The return set is the code flash image, the data flash as a separate file with its base address, the configuration words, the identification words as read, a disassembly with the vector table resolved, and a description of the persistence scheme found in the data array.

That description is the part of the report that changes customer behaviour. A customer who learns their product commits a whole block on every settings change will schedule the fix; one who already knew will nod and move on.

The half-capacity member of the same group is in R7FA2L1A93CFP binary recovery. The access window that may cover part of this array is in R7FA2L1AB2DFL flash recovery, and what heat does to everything stored in flash over years in R7FA2L1AB2DNE binary recovery.

FAQ

Is there an EEPROM on this part? No. There are two flash arrays. Persistent data lives in the smaller one.

Can the data array be written a byte at a time? Not at the hardware level. The operation is a block erase followed by a block program, whatever the software interface appears to offer.

Why deliver it as a separate file? Because it has a different base address and a different programming operation. A merged image cannot be restored correctly.

Conclusion

Eight kilobytes of persistent storage on a part with no EEPROM is a design constraint disguised as a feature. The array is flash: block erased, block programmed, and vulnerable to power loss across the whole block rather than one byte. Reading it is trivial and must produce its own file. What the firmware does to work around the constraint — log, ping-pong, or full rewrite — is visible in the dump and is usually what the customer needed to know.

Comments are closed.