Every recovery has a cheapest possible route and a most reliable one, and they are rarely the same. On the RX62T group the cheapest route is boot mode: hold the device in a special reset state, talk to it over an ordinary asynchronous serial port, and let the on-chip firmware accept commands. No debugger, no adapter, no package work, no die.

For a part that is not protected, this is a fifteen-minute job and it should never be quoted as anything else. The engineering value of this page is in the failure cases, because boot mode fails in ways that look like damage and are not.

The order code here is R5F562T6EDFF#V3: RX62T group, one of the two memory classes the group offers, and a QFP-type package code. The three fields that matter for this route are the group, which fixes the boot protocol, the memory class, which fixes the expected image length, and the package, which decides whether the serial pins can be reached without removal.

Two ways in, and one way through

The middle row is the one engineers reach for first because it is familiar. The top row is the one that should be tried first because it is cheaper: two wires and a terminal program beat a debug adapter and a header that may not exist on the board.

What boot mode actually is

The device samples a mode pin during reset. With the pin in the boot state, the core does not run the application at all. Instead it runs a small program held in a dedicated area that speaks a serial protocol, and that program can erase, program and read the flash.

Three details make the difference between a session that works and one that hangs.

The first is the sequence. The mode pin has to be asserted before the reset is released and held for a specified time afterwards. A fixture that asserts mode and reset simultaneously produces a device that either runs the application or waits in an undefined state, depending on timing margins that nobody documents because the datasheet assumes you follow the sequence.

The second is the clock. Boot mode derives its baud rate from a source that does not depend on the crystal the board provides, which is convenient — the routine works on a board with a dead oscillator. It also means the first handshake can be attempted before the board’s clock circuit has been validated, and a failure there says nothing about the board.

The third is the handshake polarity. The protocol expects a specific character at a specific rate and answers with a specific character. A level shifter that inverts, or a USB-serial adapter that idles low, produces silence that is indistinguishable from a dead device.

The four conditions that make it fail

Protection is the obvious one and it is not the most common.

The most common failure is a board where the serial pins are committed. On a motor-control design the same pins often drive an inverter gate or a diagnostic header, and the boot protocol’s traffic appears on a gate driver. That is not a reason to give up; it is a reason to lift two pins or remove the part to a fixture, which is still cheaper than decapsulation.

The second is a mode pin tied to a level that makes boot mode unreachable. Designs that never intended field reprogramming sometimes strap it permanently. Nothing in the firmware can override a strap.

The third is a protection setting in the option bytes that disables the boot-mode read while leaving the erase available. This produces the most misleading failure of the four: the device answers the handshake, accepts commands, and returns an array of a single repeated value. A tool that reports “read complete” is telling the truth about the protocol and lying about the memory.

The fourth is a serial adapter that cannot hold the line idle at the required level during reset. This is rare and it is the first thing to swap when everything else looks right.

What the read gives, and what it does not

A successful boot-mode read returns the flash array, and on this group the array includes the option-setting memory at the top of the address space, because that memory is part of the same flash. That is a genuine advantage: the watchdog configuration and the protection state come back with the code rather than requiring a separate command.

What it does not return is anything that is not in the flash. Register state, RAM contents and the state of the peripherals at the moment of the crash are gone the moment power is removed. A customer investigating a field failure often wants exactly those, and the honest answer is that a boot-mode read cannot supply them.

Recording the session

A recovery that is not recorded is a recovery that has to be repeated. Three items belong in the session note, and they cost nothing to capture.

The protocol and baud rate that worked, because the next unit from the same production run will need the same settings and the engineer who found them may not be available.

The result of the first handshake, before any command was issued, because that single exchange distinguishes a live device from a dead one and it is the fact that a customer will ask about first.

The exact command sequence, including any erase, in order. This is not bureaucracy: on a protected part, an accidental erase is the end of the recovery, and the only way to know whether an erase happened is to have written down when the command was sent.

For the sibling order code where the version suffix differs and the silicon does not, R5F562T7EDFF heximal continues with the container question. For the same group where the ID code rather than the mode pin is the obstacle, R5F562T7EDFF program copying takes that gate apart. And for a part of an older Renesas generation whose boot protocol is entirely different, R8C R5F21258SNFP unlocking is the comparison worth reading.

FAQ

Can boot mode read a protected part? It can usually reach the handshake and the erase command, and the read is what the protection blocks. An erase clears the protection, which also clears the content, so the two outcomes are mutually exclusive.

Does boot mode need the board’s crystal? No. That is why it is the right first attempt on a board whose clock circuit is suspect.

Is a serial port enough, or is a special programmer needed? A USB-to-serial adapter and the vendor’s flash programming software are enough. The adapter must idle at the correct level and must not invert.

The short version

Boot mode is two wires and a handshake, and it should be the first attempt on this group every time. When it fails, the cause is usually a committed pin, a strapped mode pin, or a protection setting that answers while returning nothing. Write down the handshake result and the command order, because on this part an unrecorded erase is indistinguishable from a mistake.

Comments are closed.