There is a failure that every production engineer meets once. A device is programmed, it passes the fixture’s checks, it is assembled into a product, it powers up, it runs, and at some point it reaches an address that contains nothing. The code before that address was written and the code after it was not, and the boundary falls in the middle of a function.

Nobody wrote the file wrong. What happened is that the burn was interrupted, or the file was short, or the programmer’s device profile described a smaller array than the part. All three produce the same signature, and understanding why requires knowing what programming actually does.

R5F562T6DDFM#13 is an RX62T group part in a leadless package field, with a quality-code suffix that differs in format from the version codes used elsewhere in the family. The device has a hundred-megahertz core, an FPU, two twelve-bit converter units and the motor-control timer set.

Three operations, three units

The unit sizes are the key. Erase is coarse and program is fine, which is why a change to one byte costs a whole block and why a design that updates firmware rewrites regions rather than bytes.

It is also why a partial burn is so specific in appearance. Programming proceeds in units, so an interruption leaves everything before the interruption correct and everything after it erased. The transition is sharp — the boundary of a unit — and it is visible in a hexdump as a sudden switch from structured content to uniform value.

The half-written block

Three things can be said about a block in this state, and all three matter for a recovery.

The code before the boundary is genuine and complete. It can be disassembled, and its structure is trustworthy up to that address.

The code after the boundary is absent, not corrupt. The device will not execute a wrong instruction there; it will execute the erased value, which on this architecture decodes to something legal and typically leads to a fault or a runaway.

And the boundary itself is evidence. It marks the moment power was lost or the transfer stopped, which on a field unit is often the most useful single fact available — it says the update was interrupted rather than the update being wrong.

Why it looks like corrupt firmware

A customer reports that a unit “loses its program”. The unit is returned, the array is read, and the image looks wrong in a way that has a clean explanation: the top of the map is intact, the middle is intact, and a region in between is uniform.

Two diagnoses compete. One is a firmware defect that erased a block. The other is a programming or power event. They are distinguished by position: a defect erases the block it is working in, which is usually adjacent to the data area; a power event leaves a boundary inside the block being programmed, with the erase complete and the program partial.

The second is far more common in the field and the first is far more commonly blamed.

The blank check, and why it matters

Before any burn, the device should be blank — or should contain exactly what the operator expects. A programmer that skips the blank check will happily program over a block that still holds data, and on flash that means the result is the bitwise AND of the old and new content, because programming can only clear bits.

The consequence is a device whose image contains instructions from two different revisions, fused together. It is a rare state and an unmistakable one once encountered: code that disassembles cleanly in two styles, with a boundary that does not align to any block.

A blank check costs seconds and removes the possibility entirely.

There is a second reason to insist on it, specific to this group. A design whose calibration constants were measured on a production fixture stores them in the same flash, and a burn that erases without checking destroys numbers that cannot be regenerated. What is lost in that case, and what replacing them costs, is the subject of R5F562TAADFP binary.

What a production line needs from a binary

Four properties, and none of them is about the content of the code.

A stated length, so that a truncated file is detectable before it is burned rather than after.

A checksum, computed over the same bytes the file contains, so the fixture can verify independently of the programmer’s own verification.

A revision identifier in the file name, because files get renamed and directories get mixed.

And the option bytes included or explicitly excluded, with a note saying which. A binary that silently omits the configuration produces a unit that boots and behaves like a different product, which is a failure that takes months to surface.

For the option-area content that this decision concerns, R5F562TABDFF program covers the bundle. For the field-unit history that a partial block reveals, R5F562T7DDFF flash covers the archaeology. And for the flat-file properties that make a length check necessary, R5F562T6BDFF binary covers base and length.

FAQ

Can a half-written block be completed? The missing region can be programmed if the block was not erased again, but only from a file known to be the same revision. Programming an unknown remainder into a known block produces a device that is neither revision.

Does verification catch an interruption? It catches the case where the programmer’s verify runs after the interruption. It does not catch an interruption after the verify completed but before the device stopped being powered.

Is a re-burn always safe? Yes, because it begins with an erase. What is not safe is a burn without an erase, which is the state the blank check exists to prevent.

The short version

Erase by block, program by unit, verify by read. An interruption leaves a sharp boundary with complete code on one side and erased space on the other, and that boundary is evidence rather than corruption. Blank-check before burning, state the length and the checksum, and say whether the option bytes are in the file — three habits that prevent most of the failures attributed to firmware.

Comments are closed.