Ask three suppliers for a firmware recovery and you will receive three archives. One contains a hex file and a one-line email. The second contains the same file plus a folder of screenshots. The third contains the same file plus a short document, and the third is the only one that can be used by somebody who was not in the room.

The difference is not extra work in the sense of hours. It is a different idea of what the customer bought. A firmware recovery exists to be relied on, and reliance needs a statement of what was done, what was found and what could not be established. On a thirty-two-bit motor-control part with an option area, a clock tree and a protection setting, the list of things that “could not be established” is not empty, and hiding it is the fastest way to lose a customer three months later.

R5F562T6DDFF#V3 is an RX62T group device: hundred-megahertz core with an FPU, two twelve-bit converter units, six-channel motor timer, QFN-type package field, and a version suffix that identifies a shipping configuration rather than different silicon.

Five sections a report needs

The fourth row is the one that gets omitted and the one that matters most. A report without a limits section is not more confident; it is less honest, and the omission surfaces at the worst possible moment — when a rebuilt unit misbehaves and nobody knows whether the image or the configuration is at fault.

What belongs in the limits section on this part

Four items, on a typical job.

The clock. The crystal fitted to the board was not measured, so the frequencies stated in the report are the ones the code programs rather than the ones the hardware produces.

The external components. Anything the firmware talks to over a bus is outside the recovery, and its behaviour is assumed rather than known.

The toolchain. A rebuild is empirically equivalent, not provably identical, unless the original compiler version was established.

And the endurance state, where a data region was recovered: the wear level is reported, and the consequence of that wear is the customer’s decision rather than the supplier’s.

Stating those four costs a paragraph and removes an entire category of later dispute.

The reproducibility test

A good test of a report is whether another laboratory could repeat the work from it and get the same bytes.

Three things have to be present for the answer to be yes. The route has to be named precisely enough to follow — not “boot mode” but boot mode with the mode-pin sequence, the baud rate and the protocol version. The settings have to be recorded, including the settings that did not work, because a later engineer who tries the failing setting first will conclude the report is wrong. And the verification values have to be present, so that the second laboratory can compare rather than merely compare sizes.

A report that passes that test is also a report that answers a challenge, which on disputed work is worth more than the technical content.

Chain of custody, when the unit is evidence

A subset of recoveries are not engineering exercises. A unit from a failed product in a liability dispute, or from a competitor’s device in a patent matter, has to be handled in a way that survives a question about who did what to it.

Three practices cover it. Record the unit’s identifiers on arrival, with photographs, before any work. Record every destructive step with a timestamp, because “we opened it” is a different statement from “we opened it after the electrical tests on this date”. And keep the original state recoverable where possible — the first read, the first image, unmodified, before any decoding or repair.

That last practice is easy and frequently skipped: engineers repair a byte-swapped image and save over it, and the evidence of the swap disappears. Keep the raw read and write the corrected version to a new file.

What customers do with these documents

Three uses, and none of them is technical.

An audit, where an inspector wants to know that the firmware in a certified product matches the one that was certified. The report’s evidence section is the answer.

An insurance or warranty claim, where the question is whether a unit failed because of a defect or because of an interrupted update. The block classification from a field-unit read answers that.

And a succession problem: a product whose original developer has left, whose firmware exists only on a chip. The report plus the artefacts is the only asset that survives.

For the block classification that answers the interrupted-update question, R5F562T7DDFF flash covers the archaeology. For the session-level evidence that a behaviour question needs rather than a copy, R5F562T6ADFF binary covers the second access route. For the configuration that must appear in the evidence section, R5F562TABDFF program deals with the option area. And for the timing statement that belongs in the limits, R5F562T6DDFF program covers the clock tree.

FAQ

Is a report required, or is it a courtesy? It is the part of the delivery that makes the rest usable. Without it the customer has files they cannot defend.

How long should it be? Two to five pages for a routine recovery. The length is set by the limits section, not by the method section.

Should unsuccessful routes be documented? Yes. A record of what failed is the most reused content in the whole document.

The short version

Five sections: scope, method, evidence, limits, artefacts. The limits section protects both sides, the method section makes the work repeatable, and the evidence section answers a challenge. Keep the raw read unmodified, and state the clock, the external assumptions and the toolchain as assumptions rather than letting them pass as facts.

Comments are closed.