The second article on the R5F100FE looks at the part from the direction its
update machinery faces: the two four-kilobyte boot clusters, the boot flag
that swaps them, and the flash shield window that keeps a field update from
running past the blocks it was authorised to touch. stays on the update path and what a recovery has to record about it.

Two clusters and one flag

The 64 KB array divides into sixty-four one-kilobyte blocks, and blocks
zero to three form the boot cluster that the device starts from. A second
cluster occupies 02000H to 03FFFH, and the boot flag, a pair of bytes in
block 0, decides which cluster is mapped at address zero after reset. The
flag is written by the documented library call that inverts it, and the
chip boots from the other cluster immediately after the next reset. The
option bytes at 010C0H and the identifiers at 010C4H are duplicated in the
second cluster, because the swap exchanges them along with the code.

Why field updaters love this arrangement

An updater erases the inactive cluster, writes the new firmware into it,
verifies it, inverts the flag and resets. A power failure at any point
before the inversion leaves the old cluster live and the unit running; a
failure after it leaves the new cluster live and, if that image is
incomplete, the fallback is to invert again. The design turns a bricking
risk into a recoverable state, which is why so many 64 KB images on this
part use the feature, and why the swapped state is normal on boards that
have been in service.

What the swap state tells the analyst

The active cluster holds the firmware that is running; the inactive one
holds the previous generation, or a half-written new one if an update
failed. Comparing the two reconstructs the update history block by block.
The wear-levelled counters in the 4 KB data flash date each inversion. On
boards that arrive dead, a half-written inactive cluster with a live old
cluster is the signature of an update that failed at the end, and the
repair is to finish the write, not to start over.

The shield window around the update

The flash shield window confines every erase and write of a
self-programming session to a configured range of blocks; outside it the
commands fail. Firmware authors set the window to the blocks the updater
touches and nothing else, so a runaway pointer cannot destroy the
application. The window’s configuration lives with the security settings
and is captured with the image, because writing a repaired board back
without restoring it removes the protection the original authors relied
on.

Reading the whole arrangement

A complete capture on this part is the active cluster, the inactive
cluster, the boot flag, the option block and both data arrays, verified
per block. None of the reads are gated by any protection, so the entire
arrangement can be recorded passively before anything is modified. The
bench work happens through the 0.8 mm leads of the LQFP, which keep
fixtures, adapters and lifted-part work all straightforward, and the
physical last resort remains the IC decapsulation service route.

Row and family context

The 48-pin
sibling with the same memory is R5F100GE program memory. The shield window in the
32-pin context is described under R5F100BD program memory. The imaging workflow is
the firmware extraction service page, the reproduction path is IC clone service, and the family
service index is microcontroller unlock.

Timing the swap safely

The inversion of the boot flag is the one moment in an update sequence
where the array is structurally vulnerable: the erase block holding the
flag also holds the vectors and the security bytes. The library
therefore sequences the operation as erase, reprogram of everything the
block lost, verify, and only then the inversion itself, with the
shield window limiting what the running code can touch meanwhile. A
session that repairs an update-damaged board replays that order
exactly rather than improvising, because the ordering is what
separates a recovered unit from a second failure. Supply stability
during the sequence is verified beforehand, and the session notes
record the flag’s state before and after. Boring, fixed ordering is
the point: improvisation at the flag is how the first failure
happened.