A part that refuses an erase is usually described as locked. The description is not wrong, but it collapses three separate mechanisms into one word, and the mechanisms fail differently — which means the word hides the diagnosis.

On this family the mechanism that refuses most erase attempts does not lock anything. It draws a boundary. Inside the boundary the array behaves normally; outside it, erase and program are declined. Reads are untouched, because reading was never what it restricted.

Three mechanisms, three scopes

The third row is the broadest and the least common. The second row is the one that stops a bench before it starts. The first row is the one that produces the confusing report: a tool that can see the part, can read some of it, and cannot change a region.

What an access window is

Two addresses are stored in the configuration area: a start and an end. Together they define a range that may be programmed or erased. Outside that range, the flash controller declines the operation.

The second row is by far the most common in a real product, and it exists for a good engineering reason: a field-update mechanism that can rewrite everything can also destroy the bootloader, and a device with a broken bootloader is a device that has to come back to the factory. Restricting programming to the application region makes an interrupted update recoverable.

The fourth row is what a customer experiences as «the chip is write-protected». It is not the same as a read block, and it usually surprises the customer that the array can still be read out.

The symptom that identifies a window

A window does not produce a uniform refusal. It produces a boundary, and boundaries are recognisable:

• An erase of the whole array fails, but an erase of a specific block succeeds.
• A program at a low address succeeds, and the same program at a high address fails with an error rather than silently doing nothing.
• A blank check reports the array as programmed in regions the tool believed it had erased.

The third one is the most diagnostic and the most frequently misreported. A tool that claims an erase succeeded, followed by a blank check that reports content, is telling you that the erase was declined for part of the range and accepted for the rest.

Reading is a separate question

Because the window restricts programming, it is entirely possible to read an array whose every writable address is protected. That combination confuses customers who expect protection to be symmetrical, and it is worth stating in a report before it is asked about.

The question «can the contents be read» is answered by the debug session, not by the window. If a session can be established — identification words matched, interface available — the array is readable regardless of how tightly the window is drawn. If a session cannot be established, the window is irrelevant, because nothing will be attempted.

That ordering matters for planning. Establish the session first, then consider the window. A bench that spends a day fighting a write refusal on a part that could have been read in ten minutes has worked the problem backwards.

Why a window is good news, not bad

For a recovery, a window that covers only the application region is a signal that the design has a field-update path and a bootloader. That has three consequences, and all of them help:

1. The bootloader is in the part, in a region the window protects, and it is a self-contained piece of firmware that can be read like any other code.
2. The application region is the part that gets rewritten in the field, which means the image it currently holds may be an update rather than the factory build.
3. The update mechanism itself — how the new image is delivered, verified and applied — is visible in the bootloader, and it often answers the customer’s real question about how their product behaves after a failed update.

Point two is the one that changes what a report should say. If the product has a field-update path, the image in the part is not necessarily the image that was tested.

What the deliverable contains

The return set is the code flash image at its full length, the data flash as a separate file, the configuration words from their fixed addresses including the window boundaries as decoded, the identification words as read, a disassembly with the vector table resolved, and a description of the update mechanism where one exists.

Reporting the window boundaries as addresses rather than as «protected» is worth the extra line. It tells the customer which region their own production fixture can change, which is a fact about their process that they frequently do not have written down.

The handshake that gates the session is covered in R7FA2L1AB2DFN locked program recovery, the route that avoids the debug port in R7FA2L1AB2DFM software recovery, and the configuration words that sit alongside the window in R7FA2L1A92DFL flash recovery.

FAQ

Does the access window prevent reading? No. It restricts programming and erasing over a range. Reads are a different path.

Why would a design set a window over nothing? Deliberate write protection. It is used where a product must never be modified, including by its own firmware.

Can the window be removed? Changing it is itself a programming operation, so a window that covers the configuration area may prevent its own alteration. Where it does not, the change requires the same session the window was never blocking.

Conclusion

Three mechanisms, three scopes: the window restricts a range of addresses, the handshake restricts a session, the life-cycle state restricts an interface. Only one of them is about writes, and it is the one that produces boundary-shaped failures rather than uniform refusals. Reading the shape correctly turns «locked» into an address range and a plan.

Comments are closed.