Two ordering codes in this group differ by one character: the code flash letter. Everything else is identical — the hundred-pin body, the industrial grade, the 105 °C range, the core, the peripherals, the RAM.

Halving an array is a small change in the code and a large change in behaviour, because the address map that surrounds it does not move. The vector table is at zero on both. The RAM is at the same place on both. Only the space between the end of the vectors and the start of the next region changes, and half of what a developer assumed was available is not there.

What the two members share

Every row except the last is identical, and that is the trap. A tool that identifies the part from its core, its peripherals or its package will identify both members the same way. The only thing that distinguishes them is a capacity, and capacity is the one property a read does not announce.

Why an image does not state its own size

A flash image is a sequence of bytes. It has no header that says how large the array it came from was, because on a microcontroller there is no need for one: the code runs from a fixed address range, and the linker was told what that range was.

What the image does contain is evidence, indirect but reliable:

• the reset vector points somewhere inside the array, and its value is a lower bound on how much code exists;
• the highest address referenced by any branch or literal is a second lower bound;
• the vector table’s length is fixed by the peripheral set, so the region immediately after it is always code.

None of those tells you the array size. All of them together tell you the minimum size the code requires, which is the number that matters when the question is whether this image fits somewhere.

The tail is the only direct evidence

Erased flash reads as all ones. A 128 KB part read as though it were 256 KB returns its real contents followed by 128 KB of erased values, and that pattern is indistinguishable from a 256 KB part whose upper half was never used.

This is the same ambiguity that appears on every part with more advertised capacity than used capacity, and it has the same resolution: read a location that must be non-blank if the part were the larger one. There is no such location on a device that was never fully programmed.

The fourth row is decisive in one direction only. Code that reaches above the 128 KB boundary proves the part is the larger member. Code that stays below proves nothing, because most code does.

Restoring larger code into smaller silicon

This is the failure that matters commercially, and it is quiet. A 256 KB image written into a 128 KB part does not necessarily fail at the write. Depending on the tool, the write is truncated at the array boundary, or the part reports an address error partway through, or the tool never checks and reports success.

The result is a device holding the first half of a program. It boots, because the vector table and the initialisation code are at the start. It runs, because the main loop is early. It fails when execution reaches an address that does not exist — which is often in a rarely used path, a diagnostic function, or a table lookup, so the failure appears much later than the cause.

The second row is why capacity belongs in a report even when the array read fine. It is the fact that determines whether the image can be used at all.

Establishing the member from the silicon

Where the image is ambiguous, the part itself can answer. The flash controller knows its own geometry, and a query through the boot firmware or the debug port returns the region layout rather than a generic identity. That layout states where the array ends, which is the size.

Where neither route is available, the physical marking on the package carries the ordering code, and the code carries the letter. That is the least technical path and the most reliable one, provided the marking is honest.

What the deliverable contains

The return set is the code flash image at the length the part actually has, 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 the array size with the evidence for it.

Stating the evidence matters more here than on a part with one capacity. «128 KB, established from the region layout reported by the flash controller» is a sentence a customer can rely on; «128 KB» alone invites the question of how anybody knows.

The 256 KB sibling with an otherwise identical ordering code is in R7FA2L1AB3CFP software extraction. The separate data array that both members share is in R7FA2L1A93CFN binary recovery, and the identifier that survives a move between parts in R7FA2L1A92DFP heximal recovery.

FAQ

Can the capacity be determined from a hex file? Not from a header, because there is none. From the highest address used, you get a lower bound only.

Does a 128 KB image run on the 256 KB part? Yes, unchanged. Every address it uses exists on both.

Why does a truncated image still boot? Because the vector table and the initialisation code are at the start of the array. The failure appears where execution first reaches the missing region.

Conclusion

Halving an array leaves every identifying feature intact and removes half the space, which is why capacity has to be established rather than assumed. The vector table proves the image is valid; the tail proves nothing on its own; the flash controller’s own region layout proves the size. Report the size together with how it was established, and the image becomes something a customer can safely use.

Comments are closed.