Most protection discussions assume a single lock with a single behaviour: it is either open or it is closed. This family has at least three distinct mechanisms, and the one that stops most first attempts is not the one that protects the flash.

It is an identification handshake, four thirty-two-bit words long, and its purpose is to answer a question that has nothing to do with content: is the tool connecting to this device authorised to do so?

Where the four words live

The identification words are stored in the code flash array, in a fixed region that is part of the configuration area rather than part of the program. They are written once, normally during production programming, and they are compared against what the debug tool presents when a connection is attempted.

The last two rows are where the confusion lives. A mismatch does not produce a «read refused» response to a read command. There is no read command. The session never opens, and the tool reports a connection failure, which at the bench is indistinguishable from a wiring fault, an unpowered target, or a part that is not there.

What a connection attempt actually looks like

A debug connection on this architecture proceeds in stages, and knowing which stage failed is the whole diagnostic:

The third row is the one this part adds, and it is the one that produces «refused» rather than «failed». A tool that says it found the target but cannot establish a session is telling you something specific: the electrical layer works and the authentication layer does not.

Wrong identification against no identification

These are different situations and they lead to different next steps.

A device whose identification area has never been programmed presents erased values. In that state there is effectively no gate: the comparison has nothing to compare against, and a connection normally proceeds. This is the state most development boards are in, which is why an engineer who has only worked with dev boards has never seen the handshake.

A device whose identification area holds values that do not match what the tool presents is a device where the gate exists and is closed. Nothing about the flash protection has been touched; the array may be entirely readable once a session exists.

That distinction matters commercially. A customer reporting «the chip is locked» is usually reporting the second case, and the correct response is not a quotation for decapsulation — it is a conversation about whether the production fixture recorded the identification words, because if it did, the job is a configuration exercise rather than a silicon one.

What the handshake does not cover

Two things are outside it, and both are worth knowing before concluding that a part is inaccessible.

The first is the array itself. The identification words gate the debug session, not the flash contents. They are a different mechanism from the access window, which is what actually limits which addresses may be programmed or erased.

The second is the boot firmware. A part can be entered through its serial boot path with a mode pin and a serial pair, without a debug session at all. Whether that path performs the same identification check depends on the device state and the firmware version, and the honest answer is that it must be tested rather than assumed — in either direction. Assuming it is unchecked leads to wasted effort when it is; assuming it is checked leads to a job sent away that did not need to be.

Four rows, four independent failure modes. That is why a single «it is locked» report is not actionable, and why the first task on any such part is to determine which row is the one refusing.

Establishing which one refused

A short sequence, in order of cost:

1. Power and ground, confirmed at the pins rather than at the supply.
2. Mode pin level at reset, confirmed rather than assumed.
3. A connection attempt, with the tool’s own diagnostics read carefully: found-but-refused is a different result from not-found.
4. If the boot firmware path exists, try it. It is cheap and it answers the question about whether the refusal is debug-specific.
5. Only then consider the package.

Steps one to four take under an hour and they resolve the majority of «locked» reports without any work on the silicon.

What the deliverable contains

Where the handshake is satisfied and the array is read, the return set is the code flash image, the data flash as a separate file, the configuration words, the identification words as read, a disassembly with the vector table resolved, and a statement of which mechanism was encountered.

Where the handshake cannot be satisfied and no record of the words exists, the report should say so explicitly, together with the evidence: the stage at which the connection failed and what the tool reported. That sentence is what allows the customer to decide between a production-fixture fix and a silicon job.

The separate mechanism that limits which addresses may be changed is covered in R7FA2L1AB2DFL flash recovery. The route that avoids the debug port altogether is in R7FA2L1AB2DFM software recovery, and the ordering code itself in R7FA2L1AB3CFP software extraction.

FAQ

Does a refused connection mean the flash is protected? No. It means the session did not open. Flash protection is a different mechanism and may not be set at all.

Can the identification words be read back? Sometimes, through a route that does not require a session. Where they can be read, the gate’s state is known before any attempt.

Is it worth trying the serial boot path? Yes, and first, because it costs almost nothing and it distinguishes the two failure classes.

Conclusion

A part that will not let a debugger in has not necessarily protected anything. The identification handshake is a door policy, separate from the lock on the room, and the two fail with different symptoms. Reading the symptom correctly is what turns a «locked chip» into either a configuration question or a silicon job — and those two answers differ by an order of magnitude in cost.

Comments are closed.