There is a class of recovery failure that produces a complete, byte-accurate, correctly checksummed image which is nonetheless the wrong program. It happens on dual-endian architectures, and the RX family is one of them. The core can execute big-endian or little-endian code, the choice is latched at reset from a mode pin, and nothing in the flash records which way the board was wired.

So a recovered image carries the bytes but not the interpretation. Delivering it without stating the byte order is like delivering a document without saying which language it is in: the pages are all there and none of them can be read.

The device here is R5F562T7BDFF#V3, an RX62T group part: thirty-two-bit core at up to a hundred megahertz, single-precision FPU, two twelve-bit converter units, six-channel motor timer, and the inverter-oriented protection logic that makes the group common in drives. Note what the trailing letters do not encode — the B in the base code is part of Renesas’s variant scheme, not an endianness flag, and treating it as one is a reliable way to get the analysis backwards.

Three places byte order shows up

Only the first row is a hardware decision, and it is the one that matters most. A design that chose big-endian for compatibility with an existing network protocol and a design that chose little-endian because that was the default both produce a flash image that is a valid RX program. There is no flag, no header byte, no option-memory field that distinguishes them.

What a swapped image looks like

RX instructions are variable length: two, three, four or six bytes, and the length is determined by the pattern of the first byte. That has a specific consequence for a swapped image.

If the whole file is byte-reversed in four-byte groups, the first byte of every instruction is whatever byte happened to be at the end of that group. Instruction lengths then decode wrongly, and the listing wanders through the image at the wrong stride — sometimes consuming two bytes, sometimes six, never settling. The result does not look like a program with a few bad instructions. It looks like noise that occasionally produces a plausible branch.

If the file is swapped in two-byte groups instead, the effect is subtler. Sixteen-bit thumb-like instructions decode into different but legal instructions. The listing looks like real code, runs off the end of functions, and jumps to addresses that are inside the image but never at a function boundary. This is the more dangerous of the two, because it survives a superficial review.

The four bytes that settle it

The RX address map puts the reset vector at the very top: the last four bytes of the four-gigabyte space hold the initial program counter. That is a gift for verification, because a valid image must contain a plausible address there, and plausibility is easy to define — the value should fall inside the flash region, not inside the option-setting area, and it should be a multiple of two, usually of four.

Read those four bytes in both orders and compare. One of the two will be an address inside the flash; the other will be a number like eight hundred million, which is not an address anything can execute from. The test takes ten seconds and it distinguishes the two swaps as well as confirming that the image is not truncated.

The same logic applies at the exception vector area just below the top of the map. Those entries point at handlers, so they must also be plausible addresses, and a block of entries that all decode to nonsense in one order and to clustered, tightly spaced addresses in the other is conclusive.

Repairing the swap correctly

Repairing is not simply reversing the file. The right transformation depends on where the swap was introduced, and there are three distinct cases.

A read performed with the device’s byte order inverted produces a file that is wrong in four-byte groups if the reader assembled words, and in two-byte groups if it transferred halfwords. Comparing against the vector test tells you which.

A file converted by a tool that assumed the wrong endianness produces a clean four-byte reversal. That is the easy case: reverse the groups and the image is correct, no information lost.

A file that has been through both a reader and a converter can be wrong in a way that is not a uniform transformation at all. This is rare and it is detectable, because no single transformation makes both the reset vector and the exception vectors plausible.

Why this matters for code rather than for data

A byte-swapped data table is annoying. A byte-swapped code image is a false result, because it will produce a listing that a reviewer may accept.

The review habits that catch it are worth stating. Check the reset vector first, always, before reading a single instruction. Check that every function the disassembler identifies begins with a plausible prologue for the compiler family that was used. And check that the number of function starts is in the range the image size implies, because a wrongly strided listing produces either far too many or far too few.

None of those checks requires knowing the firmware. All of them fail loudly on a swapped image.

For the container that has to carry a thirty-two-bit vector address without losing it, R5F562T7EDFF heximal deals with record formats. For the disassembly pass that follows a correct read, R5F562T7BDFF code recovery continues. And for a lock-bit problem rather than a byte-order problem on the same group, R5F562T6EDFF program copying covers the authentication gate.

FAQ

Can the endianness be changed after the fact? The image can be converted, but the board cannot. A converted image will not run on the original hardware unless the mode pin is also changed, which means a board modification.

Does the order code say which endianness was used? No. It is a reset-time pin selection, so the same order code ships into both kinds of design.

Is a two-byte swap ever correct? It is correct when the reader transferred halfwords with the wrong order. It is never correct as a final deliverable unless the vector test passes on the result.

The short version

Byte order on this part is a wire, not a byte. Check the four bytes at the top of the map before reading a single instruction, because they settle the question in one comparison. Then state the endianness in the delivery note, next to the option bytes and the clock configuration — three facts that are not in the image and that determine whether a rebuilt unit behaves like the original.

Comments are closed.