The most expensive mistake in this trade is not a failed read. It is a read that succeeded at the protocol level and returned nothing, because the file then goes into a report, the report goes to a customer, and the customer spends a week trying to work out why the disassembly is nonsense.

On the RX62T group this failure has a specific signature, and once you have seen it the diagnosis takes seconds. The device completes the handshake, accepts the read command, transfers the requested number of bytes at the requested rate, and every one of those bytes is the same value. The transfer is real. The data is not.

The part here is R5F562T6EDFF#V1. The fields that matter are the group, which fixes the command set, and the memory class, which fixes how many bytes a genuine read should return.

The matrix

The bottom row is not a protection state at all, and it is the one people spend the longest on because a dead fixture and a locked device look identical from a terminal window. The distinction is made by measurement rather than by software: check the mode pin level during reset, check that the serial lines idle at the correct level, and check that the device is actually receiving a clock or that boot mode is genuinely independent of it.

The two middle rows are worth internalising as a pair. Protection and the ID code are independent, and the four combinations all occur in shipping products. A device with an erased ID and protection on is not a device with no protection; it is a device that opens the door and then refuses to show you the room.

Why the repeated value is not a bug

A protected array does not return an error because the protocol has no field for one. The command completes, the byte count is honoured, and the logic returns a fixed pattern in place of memory content. Some revisions return all ones, which is also what an erased cell returns, which is why the failure is commonly misdiagnosed as “the part is blank”.

There is one reliable way to tell blank from protected, and it does not depend on the value: read the top of the map and compare it against the bottom. On a blank device the option-setting area and the vector area are also erased, so the values there are the erased pattern. On a protected device the interface is returning a constant that has nothing to do with address, so the value at the top of the map is identical to the value at the bottom of the array. Real memory is never uniform across a four-gigabyte map, and an erased device is uniform only because it is genuinely empty.

That test — uniformity across regions that could not plausibly hold the same byte — separates the two cases in one command.

The one-way trade

The protection setting lives in the option-setting memory, which is part of the same flash array. Clearing it requires an erase, and an erase of the option area on this family is performed as part of a chip erase that also removes the application.

So the trade is exact and there is no way around it through the interface: you may have a blank, unprotected device, or you may have a protected device with its content, and not both. Every route that produces the content therefore goes through the die rather than through the pins.

This is worth stating plainly to a customer early, because the alternative belief — that a protection flag can be “flipped” — leads to expectations that no amount of bench work will satisfy.

Verifying a read that looks successful

Once the array answers, the question becomes whether the bytes are right. Three checks, in increasing cost.

The first is the vector test at the top of the map, which proves the base address, the endianness and the completeness of the file in one comparison.

The second is a block comparison against a second read. Read the same region twice, ideally with the probe or the adapter re-seated in between, and diff. Disagreements localise to specific addresses, and those addresses are the ones to re-read rather than to average.

The third is a checksum computed independently of the tool. RX devices include a checksum facility for flash, and a value computed by the device can be compared against a value computed from the file. Where the two agree, the transfer is proven end to end rather than merely plausible.

What travels with the array

An array on its own is not a firmware image. Three things sit outside it in meaning even though they sit inside it in address space.

The option-setting memory, which holds the watchdog configuration and the protection state, and which must be reported separately because it changes behaviour rather than content.

The reset and exception vectors, which are part of the array but which belong in the delivery note as a map rather than as bytes.

And the clock configuration, which is not in the flash at all but which the option bytes and the code both assume. A rebuilt unit on a different board revision will start and run at the wrong speed, and that symptom will be blamed on the recovery rather than on the missing note.

For the authentication gate that sits in front of this read, R5F562T7EDFF program copying covers the ID exchange. For the packaging of the result, R5F562T7EDFF heximal deals with record formats. And for a locked Renesas part where the whole array had to come off the die, readout of a locked R7F7010124AFP shows what that engagement looks like.

FAQ

Does a protected RX62T return an error code? No. The command completes and the byte count is honoured, with a fixed value in place of content.

Is all-ones a sign of protection or of a blank part? Both, which is why the value alone cannot decide it. Uniformity across the top and bottom of the map is the discriminator.

Can the protection be cleared without erasing the array? Not through the programming interface. The setting lives in the same flash that the erase removes.

The short version

A successful transfer is not a successful read. Learn the matrix, test the top of the map against the bottom, and treat a uniform array as a statement about the interface rather than about the memory. Then verify whatever does answer with three checks — vector, second read, independent checksum — and send the option bytes and the clock note along with the bytes.

Comments are closed.