A read that returns bytes is not a deliverable. Bytes can be returned by a tool that used the wrong base address, that read an array half the size it was told, or that produced a file with the regions in the wrong order.

What makes a result usable is a set of checks that a customer can repeat, and a report that distinguishes what was established from what was assumed. This last page in the series is about that end of the work.

The five checks

Every image that leaves a bench should pass all five, and each of them catches a different class of error.

The first is free and instantaneous. The second requires knowing the device’s capacity, which is the argument for establishing it rather than assuming it. The third distinguishes a part that was programmed from one that was not.

Self-validation from the first eight bytes

The vector table does most of the work, and it does it without any knowledge of the firmware.

The first word is the initial stack pointer. On this family it should point to the top of a thirty-two kilobyte region, so its value falls in a narrow, recognisable band. A value outside that band means either a different part or a shifted base address.

The second word is the reset handler address. It should fall inside the code flash range, and its least significant bit should be set, because on this architecture the bit marks the instruction state. A reset vector with that bit clear is not a valid entry point.

The last two rows are worth separating in a report. All zeros and all ones are different failures: one is a bus that returned nothing, the other is an array that was erased or a tool that filled its buffer with the erased value.

Why block checksums, not just one

A single checksum over the whole image answers one question: does this file match that one. It does not tell you where they differ, and on a large image that is the difference between a five-minute diagnosis and an hour.

Block checksums — a cyclic redundancy value per region, typically a few kilobytes — localise a discrepancy immediately. Where the customer has a reference image, comparing block values identifies the damaged region without transferring either file.

The third row is what a good report carries when a comparison was possible.

What the report has to state

A recovery report is not a narrative. It is a set of statements that a customer can act on, and six of them are non-negotiable on this family.

The last two are the ones most often missing and most often decisive. A complete image that omits the configuration words produces a device that resets in a loop; an image bound to a unique identifier produces a device that runs and cannot authenticate.

Three files, three addresses

The deliverable is three files and each has its own base address, stated explicitly:

• the code flash image, at the start of the array;
• the data flash image, at its separate segment;
• the configuration and identifier values as a short table.

The addresses are not decoration. A programming fixture that writes the data image at address zero destroys the device it was meant to restore, and that mistake happens because the two arrays are delivered together and look alike.

What verified does not mean

A verified image is one whose contents were read consistently and whose integrity checks pass. It is not a claim that the contents are original, unmodified, or the version the manufacturer shipped.

That distinction matters where a product has a field-update path. The image in the part may be an update, a partial update, or a diagnostic build left behind by a service tool. The report can say which of those the evidence supports — an interrupted page, a version string, a build date — and should not present the result as the factory image without evidence.

The last row is the one to be careful about, and saying so plainly is better than letting a customer assume it.

Closing note

The twenty pages in this series each take one ordering code and one technical question. Read in order, they describe a single device family from the ordering code outward: the fields that matter, the three access doors, the window that limits writes, the two identifiers, the data array that is not an EEPROM, the clock tree, the analogue and touch front ends, the arithmetic without an FPU, the supply range, the configuration words at the bottom of the array, and finally what a finished job contains.

The entry point for the family is R7FA2L1AB3CFP software extraction, where the ordering code is decoded field by field. The two array sizes and the boundary between them are in R7FA2L1A93CFP binary recovery, the write restriction in R7FA2L1AB2DFL flash recovery, and the configuration words that decide reset behaviour in R7FA2L1A92DFL flash recovery.

FAQ

What proves an image is complete? Its length against the device capacity, plus a blank check on regions that should be empty, plus a vector table that decodes correctly.

Is one checksum enough? For equality with a reference, yes. For locating a difference, no.

Can a report claim the image is the factory build? Only with evidence such as a version string. A read establishes what is in the part, not where it came from.

Conclusion

The last mile of a recovery is verification and honesty. Five checks catch the mechanical errors, block checksums make a discrepancy locatable, and a report that separates established facts from assumptions is what allows a customer to rely on the result. An image that passes those checks is a faithful copy of what the part holds — and that, stated precisely, is a stronger claim than «recovered».

Comments are closed.