A unit that arrives from the field is rarely running the firmware its product was launched with. It has been updated, possibly several times, possibly by a technician with a laptop and a serial cable, and possibly with a procedure that was interrupted. All of that history is still visible in the array, because flash cannot be edited — only erased by block and rewritten.

That property is what turns a recovery from a copy into an investigation. A customer who asks for “the firmware from this unit” may be asking for the current revision, for the revision they think is installed, or for the one that produced a failure. Those are three different answers and the array contains all three if you read it in the right order.

R5F562T7DDFF#V1 is an RX62T group device: thirty-two-bit core, FPU, two twelve-bit converter units, motor-control timer set, QFP-type package. The version suffix identifies a shipping configuration rather than different silicon, which is worth stating because customers sometimes read the hash code as a revision indicator for the firmware. It is not.

What a block-level read shows

The third row is the one that produces the most useful answer, and it is not obvious from a byte comparison alone. It comes from looking at compiler-generated patterns: a block written by a later revision of the firmware frequently uses slightly different register allocation, or a different constant-pool layout, or a slightly larger function at its start. Those differences are invisible in a hexdump and obvious in a disassembly of the first few hundred bytes of each block.

Why an interrupted update leaves a readable state

The programming sequence for a block is erase, then program, then verify. An interruption between any two steps leaves a state that is not “old code” and not “new code”.

An interruption after the erase and before the program leaves an erased block: uniform, and thus trivially recognisable. A device in this state usually will not boot, and it is the best case, because the damage is obvious.

An interruption during the program leaves a block that is part new and part erased. The code disassembles for as long as the written portion lasts, and then becomes uniform. This is the state that produces the classic “it worked until we updated it” report, and the boundary between the two regions is the exact point at which power failed — which is a specific, reportable fact.

An interruption during the verify step leaves a fully written block, possibly with a defect that the verify would have caught. This is the worst case, because the unit boots and misbehaves, and nothing in the array looks wrong until a comparison against a known-good image is done.

Reading the array as a sequence

The order that produces a usable history is short.

Read the whole array in one pass, so that the block boundaries are consistent with a single session. Read the option area and the vectors first, because they tell you whether the device is protected and which revision booted last.

Then walk the image block by block and classify each block: code, table, erased, or mixed. That classification is mechanical and it can be done on a hundred-kilobyte image in a few minutes.

Then compare the classification against the product’s documented layout. A design whose linker script places code in the first half and tables in the second will show a clean split; a design that has been updated twice will show a code block in the middle of the table region, and that is a fact worth reporting rather than a defect worth fixing.

What the customer actually needs to hear

Three sentences, and they are worth separating because the answers are often different from what was asked.

The unit is running revision X, identified by the version string and by the structure of the code, not by anything the customer told you.

Blocks A through C were rewritten after production, which means the firmware was updated in the field and the update completed.

Block D contains a partially written region, which means an update was interrupted, and the device has been running on code that was never fully written.

That third sentence changes the whole engagement. A customer investigating a field failure on a unit with a half-written block does not need a recovery; they need to know that the failure is explained, and no amount of die work will improve on that answer.

Where this changes the quotation

A recovery quoted as “read the array” assumes the array is one thing. On a unit with a documented update history it is at least two, and the analysis that separates them is real work with a real deliverable.

The honest structure is two lines: a read, priced as a read, and an analysis, priced separately. Customers accept that structure readily once the difference is explained, and they resent it deeply when it appears as an unexplained addition after the read is done.

For the protection state that may prevent the read at all, R5F562T6EDFF flash covers the diagnostic matrix. For the version string that answers the revision question, R5F562T7ADFF binary shows where to look. And for what programming does to a block in the first place, R5F562T6DDFM binary takes the write sequence apart.

FAQ

Can a field update be undone from a recovered image? The previous revision is gone from the flash it overwrote. What remains is whatever survives in a second block, a backup region, or the customer’s own archive.

Does an interrupted update damage the device? It leaves the array in a mixed state. The device is not damaged; it is running, or failing to run, on partly written code.

Is a block-level classification reliable? It is reliable for distinguishing code from erased space and from tables. Distinguishing one code revision from another needs a disassembly comparison, which is a slower and more certain test.

The short version

Flash keeps its history in block granularity. Read the whole array in one session, classify every block, and look for the block whose character differs from its neighbours — that is the one a later revision rewrote. Then tell the customer which revision they are holding and whether an update completed, because on a field unit those two facts explain more failures than any amount of die work.

Comments are closed.