Most recovery work assumes a binary outcome: the image is readable or it is not. Real devices produce a third answer, and it is the one that requires judgement. Part of the array reads cleanly, part of it reads with errors, and the customer needs to know which of their values survived.

On a device of this size the units are easy to hold in mind. Sixty-four kilobytes, divided into eight sectors of eight kilobytes each. Every erase costs one of those eight. Every record the product ever wrote lives inside one of them.

Why the sector is the unit that matters

Flash is erased in blocks, and the block is the smallest thing that can be returned to a blank state. A single byte cannot be rewritten without erasing its whole sector first, which is why firmware that stores settings in flash writes them as an append-only log rather than as fixed fields.

Two consequences follow for recovery.

The first is that damage is usually sector-shaped. A sector that has been erased far more often than its neighbours wears out first, and when it does, the failures appear as bits that will not program or will not hold their state. Those failures cluster, because the whole sector was stressed together.

The second is that a partial image is still useful. If six of eight sectors read cleanly, then every record stored in those six is intact, and only the records in the remaining two are in question. Reporting that boundary honestly is more valuable than delivering a file with silent holes.

Reading the array twice

The first pass is a straight read through whichever interface is available. The second pass is the same read again, with a delay, and a comparison. Bytes that differ between passes are not code — they are cells that are marginal, and their locations point at the sector that is failing.

A third pass after a short period at temperature often separates two different faults. Cells that fail consistently are damaged. Cells whose value drifts are retaining charge poorly, which is a different repair decision and, on a device that has been powered off for years, a surprisingly common finding.

Where the settings actually sit

On a product that uses this device as a controller, the parameter store is usually the top two sectors, alternating as a log. That structure was described in LPC2119FBD64 parameter store work, and it is worth repeating the operational point: the newest copy of a record may be in either sector, so losing one sector does not necessarily lose the value.

The reconstruction rule survives partial loss. Collect every valid record, sort by sequence number, take the newest for each key, and mark the keys whose newest copy was in the missing sector. A customer who knows that one counter is stale can act; a customer who is handed a file with a plausible invented counter cannot.

Recognising a damaged record

Records written to an emulated log usually carry a marker and a checksum. That redundancy exists so the firmware can detect an interrupted write, and it is exactly what a recovery needs to distinguish a complete record from a fragment.

Fragments should be preserved and labelled. A half-written record often still contains the first fields in a known order, and on a calibration block the first fields are frequently the ones that matter. Discarding it because the checksum fails throws away information that costs nothing to keep and report separately.

When the data is only a few hundred bytes

A frequent framing of these jobs is a request for the whole device when the need is a serial number, a set of calibration coefficients, or a key. On a sixty-four kilobyte array that is a rounding error of content, and the work is correspondingly cheaper: read the sectors that plausibly hold it, identify the structure, extract the fields, and stop.

Being able to say which sectors to skip is worth quoting for. A customer who is told that sectors four through seven need not be preserved can accept a faster, cheaper job with a known gap, and that conversation is only possible when the sector map is understood from the start.

Reassembly and its limits

A reassembled image is not the same object as the original. Sectors that were read cleanly are faithful. Sectors that were reconstructed from a compaction copy are faithful in content but not in address. Sectors that were lost are absent.

The delivery should reflect that hierarchy rather than flattening it. Three levels — verified, reconstructed, missing — is enough for any customer to act on, and it prevents the situation where a file is trusted because it opened correctly.

Related material

The route that produces the array in the first place is in LPC2102FBD48 data recovery, and the older port-level approach to this same ordering code is in LPC2132FBD64 firmware work. When the array has already been erased and only a blank chip remains, LPC2104FBD48 erase behaviour explains why nothing further can be recovered from the device itself.

A closing caution

Never erase a sector in order to make it read cleanly. It is a tempting move when a sector fails verification and the content appears to be damaged, and it converts a damaged sector into an empty one, which is strictly less information. The only reason to erase anything during a recovery is to clear a protection word, and at that point the delivery has changed from data recovery to something else entirely.

Comments are closed.