There is firmware inside this microcontroller that was not written by the customer. It lives in a protected region, it runs before any application code, and it exists to accept programming commands over a serial pair.

On a dense board where the debug pins were reclaimed for I/O, that firmware is often the only route in. It is worth understanding precisely what it offers, because the common expectation — that anything able to talk to the part can also extract from it — is wrong.

How boot mode is entered

One pin is sampled while reset is asserted. At the level that starts the application, the part runs the customer’s firmware. At the other level, control goes to the boot firmware instead, and the part waits on a serial pair for commands.

Three practical points follow, and each of them trips people up:

1. The pin is sampled at reset, not read continuously. Holding it afterwards does nothing.
2. The serial pair used by the boot firmware is fixed by the silicon, not chosen by the application. It may not be the pair the board uses for its own communication.
3. If the board ties the mode pin permanently to the run level, the route does not exist regardless of what the part can do.

What the boot firmware will do

The command set is small and oriented towards production programming rather than investigation:

The second column is what the protocol does. The third column is what matters commercially, and the answer for the one command everybody wants — read this region out — is that there is no such command.

Why a successful connection is not a read

This is the point worth being blunt about. A boot firmware that can erase and program can also, in principle, be used to prove things about the array: a blank check says whether a region is erased, a checksum says whether it matches a known value. Neither of those returns the contents.

So a bench that reports «the boot mode connects, the part is not locked» is reporting something true and not useful. The part was never inaccessible through that route in the first place: boot mode access is granted by a pin level, not by a password. What the customer needs is the array contents, and the protocol does not have a command for that.

The last row is the whole job, which is why boot mode is a diagnostic tool rather than a recovery tool.

When it is still the right tool

Three situations where the route earns its place:

• Confirming the part is functional before spending money. A part that answers an inquiry is a part with a working core, working ROM and working serial. That rules out a large class of hardware failures.
• Restoring a known image. Where the customer has their own firmware and only needs the unit working again, programming through boot mode is exactly the right operation and it costs nothing.
• Testing the protection state. A part that refuses to erase a region that the boot firmware should be able to erase is telling you that the access window is set over that region. That is evidence, obtained without the debug port.

The third one is the useful one for a recovery that will end at the silicon. Knowing that the access window is set, and over which addresses, tells you what the protection configuration looks like before anything is opened.

What the array looks like from outside

One consequence of the checksum command is worth mentioning because it is occasionally useful. Where a customer has a second, working unit, the checksum over a region of the failed unit can be compared against the working one. Equal checksums do not prove equal contents, but different checksums prove different contents, and that distinction sometimes settles whether the failed unit was ever updated.

That is a weak tool and an honest one. It should be described as such in a report rather than promoted into a verification claim.

What the deliverable contains

Where the job proceeds to a read, the return set is the code flash image, the data flash separately, the configuration words, the identification words as read, a disassembly with the vector table resolved, and a note recording what the boot path reported before the read.

That note is not padding. The inquiry response, the blank check results and the region checksums are all evidence about the state of the part as it arrived, and where they exist they are cheaper and more reliable than anything reconstructed later.

The handshake that gates the debug port but not this route is covered in R7FA2L1AB2DFN locked program recovery. The board-level question of whether the route even exists on a given design is in R7FA2L1AB3CFL heximal recovery, and what a finished report should verify in R7FA2L1A92DNE program recovery.

FAQ

Can boot mode read the flash out? No. The command set covers inquiry, erase, blank check, program, checksum and jump. There is no read command.

Is boot mode protected by the identification words? That is a device-state question and it must be tested rather than assumed. The mode pin gates entry; the identification words gate the debug session.

If boot mode refuses an erase, is the part locked? It means the access window covers the region. That is a configuration state, and it says nothing about whether the contents can be recovered.

Conclusion

The serial boot path is a genuine second door and it is not a shortcut. It confirms that the part is alive, tells you what the protection configuration covers, and lets you write an image you already have. What it does not do is return the contents of the array, and a job that needs those is a debug-port job or a silicon job regardless of how easily boot mode connects.

Comments are closed.