Every family of microcontrollers teaches its own vocabulary, and customers arrive carrying the words from whichever part they used last. The word eeprom is the most persistent of them. On an eight-bit part it meant a small separate array with byte granularity and a fixed address. On this ARM7 device there is no such array at all, and yet the parameter block that the product treats as its EEPROM certainly exists.

Finding it is the first task on any job described as an EEPROM read, and it is worth doing properly, because on a board where the store turns out to be external, the job can be finished without touching the protected device at all.

Three places the data can be

In practice, persistent parameters on a product built around this part live in one of three locations, and the firmware’s behaviour on the first read distinguishes them within a minute on a scope.

The third case is more common than customers expect. A product whose calibration never changes after production often stores it in the image, and the block the customer calls the settings page is actually a set of values written into the source at build time. When that is the case, no EEPROM exists to recover, and the answer to the request is the recovered image with the constants identified and annotated.

Emulated storage in flash

Where the product does need to rewrite parameters in the field, the firmware carves two or more sectors out of the top of the array and treats them as a log. This is the standard technique on parts without a data array, and it leaves a recognisable structure.

Each record is written with a valid marker and a sequence number. A write goes to the next free slot; when a sector is full, the live records are copied to the other sector, the source is erased, and the sequence continues. Reading the content therefore means reconstructing which record of each key is the newest, not simply taking the last bytes in the sector.

The recovery procedure is mechanical once the structure is understood:

1. Read the sectors in full, including the erased space, because erased space marks the write frontier.
2. Group by record key, sort by sequence number, and keep the newest surviving copy of each.
3. Detect the copy event, because records that were promoted during a compaction have higher addresses and older sequence numbers than the ones written after.
4. Report both the logical map and the raw sectors, since a customer rebuilding the store needs the raw form as well as the interpreted one.

That work is only possible with the array in hand. On a device whose protection has been set to its highest level, the emulated store is exactly as inaccessible as the code — see LPC2101FBD48 protection states for why, and LPC2104FBD48 erase behaviour for what happens if somebody tries to unlock it.

The external memory case

If the scope shows traffic on the serial bus immediately after reset, and those transfers happen before the first output the product produces, the parameter store is on the board rather than in the device.

This is the good outcome. A serial EEPROM in a standard package is readable with a handful of connections, it carries no protection, and it can be copied byte for byte. It also survives the MCU: a board whose microcontroller is destroyed still yields its settings, which is exactly what a repair operation needs.

Identifying which device is on the bus is a matter of reading the address in the first transfer and matching it against the standard address map for the family. The content is then read as a flat image and interpreted against the structure the firmware imposes on it.

Two CAN channels, two layers of parameters

This member of the family carries two CAN controllers, which adds a second class of persistent data that is easy to miss.

A CAN node is identified by its acceptance filters and masks, by the bit timing registers derived from the peripheral clock, and by whatever node address the application puts in its payloads. All three are usually held in the same parameter block as the rest of the settings, and all three must be recovered together for a replacement unit to work on the same bus.

A copy that carries the firmware but not the filter tables produces a device that runs perfectly on the bench and deaf on the network. That failure is common enough to be worth a checklist item: when the product has a fieldbus, recover the network parameters explicitly and report them as a named section rather than as part of a generic parameter blob.

What the deliverable should contain

An EEPROM job that ends with a binary file has answered the letter of the request and only half of its purpose. A useful delivery is four things:

• the raw content, exactly as read, with the device or sector it came from
• a field map, so the customer knows which bytes are the serial number, the calibration, the counters
• the interpretation, so a human can read the values without a decoder
• the caveats, including which fields were synthesised rather than read, and which were lost

That last item matters on a device where a record was half-written when power failed. A recovery that silently invents a plausible value for a damaged field is worse than one that reports the field as damaged, because the customer will act on it.

Related reading

For the route that produces the array in the first place when the debug port is open, see LPC2102FBD48 data recovery. For the readout route on this same ordering code when the request is the firmware rather than the settings, the older LPC2119FBD64 firmware attack covers the port-level approach, and LPC2129FBD64 firmware recovery covers the network side in more detail.

The question to ask first

Before anything is measured, ask what the value is used for. A customer who needs to restore a serial number needs four bytes. A customer who needs to rebuild a production line needs the whole store. A customer who needs to understand why a unit misbehaves needs the counters and the calibration rather than the identity. The three answers lead to different depths of work, and the first one is often finished in an hour on a board whose microcontroller is never touched.

Comments are closed.