The request arrives as “we need the EEPROM contents”. On a part with a byte-writable data array that is a straightforward job. On this one there is no data EEPROM at all — the silicon has main flash and nothing else — and yet the data exists, because every designer who needed it built one in software.

That emulation is where the recovery actually happens, and understanding it is the difference between handing over a flash dump and handing over the settings that the product was last running with.

What replaced the data array

An emulated non-volatile store uses the main flash as a medium. The constraints are severe compared with a real EEPROM:

• Writes are page-granular for erasure. A page here is two kilobytes.
• Endurance is in the thousands of cycles, not the millions.
• A write can only clear bits, so an update means erasing a page and writing it again.
• Power can fail halfway through, leaving a page that is neither old nor new.

Those constraints produce a small number of standard designs, and identifying which one you are looking at tells you where the current data lives.

The ping-pong pattern, in detail

The most common design uses two pages of equal size. Each page begins with a header containing a magic value and a generation counter. On update, the firmware writes the complete new record set into the inactive page with an incremented counter, verifies it, and then erases the old page.

Two consequences follow for recovery.

First, the same data exists twice, in two pages, and only one of them is current. Delivering both without saying which is authoritative leaves the customer to guess.

Second, if power failed during the write, the inactive page may be partially written and the old page may not yet be erased. That state is recoverable — the counter on the partially written page is usually present, and the record can be validated or rejected — but it requires reading the header before deciding.

Finding it in the image

Three signals, in order of reliability.

Content, not address. Configuration data is not instructions. A page whose bytes are mostly structured, or which contains readable ASCII, or which shows repeated identical records, is not code. On this part, the last two pages of the array are the most likely candidates, because designers place the store at the top to keep it out of the way of a growing program.

Magic values. Almost every emulation starts its page with a recognisable constant. A four-byte value that appears at the same offset at the start of two different pages is a header, and the value is often a string fragment or a checksum-friendly constant.

Generation counters. Two adjacent pages with the same header and different values in a four-byte field immediately after it is the ping-pong signature. The higher value is newer, unless the counter wrapped, which it does eventually.

Which copy is current

The counter answers it most of the time. When it does not — because the counter is not monotonic, or because the store uses a checksum instead — validation decides.

Validation is application-specific and is usually visible in the firmware: a checksum over the record area, stored at the end of the header. Recomputing it over each candidate and comparing tells you which copy is intact. If both validate and the counters are ambiguous, the safer assumption is the higher counter, and the delivery should say that an assumption was made.

Why this is more than a data-recovery exercise

On a product that has been in service, the emulated store holds the things the customer actually wants: calibration constants from the test fixture, the accumulated operating hours, the last configured setpoints, the serial number.

A flash dump contains those bytes. It does not tell anyone which bytes matter or what they mean. The useful deliverable therefore includes a decoded view: the record layout, the field offsets, the current values, and the interpretation of each field where it can be determined from the firmware.

Determining it means reading the code that loads the record — a structure copy at startup, with fixed offsets into a RAM buffer. Those offsets are the field map, and they can be read directly out of the disassembly.

The wear question

An emulated store wears the flash it lives in. A device that logged a counter every minute for five years has put a substantial number of cycles through two pages, and those two pages are the most likely to have marginal cells.

If one of the two copies fails validation intermittently, that is wear rather than corruption, and the other copy is the one to trust. Reading both several times and comparing is the cheap way to confirm it before concluding that the data is damaged.

What to hand over

• The full flash image, with the store pages identified by address.
• Both copies of the record, with the current one marked and the reason stated.
• The decoded field map, as far as the firmware allows.
• A note on whether either copy failed validation.

That package lets the customer restore a replacement device to the state the failed one was in, which is the actual goal — not the bytes, but the configuration.

Related reading

• STM32G030K6 and the per-unit values a dump misses — the identifier and calibration alongside this data.
• STM32G030K8 and the four memory ranges — why the last pages are not code.
• STM32F042F4 program recovery — the same emulation problem on a smaller sibling.

FAQ

Does this part have any EEPROM at all? No data EEPROM. Everything non-volatile is main flash.

Can the emulated store be read through the application? Only if the firmware exposes it, which most products do not.

What if both copies fail validation? Then the data is damaged and the fallback is the customer’s records. Partial recovery is sometimes possible from the older copy.

Is the store always in the last pages? Usually, not always. Content identification is more reliable than address.

Conclusion

There is no EEPROM to recover, which is why the recovery is interesting. Find the two pages, read the headers, decide which copy is current, and decode the record — the bytes were never the deliverable, the configuration was.

Comments are closed.