Every memory map is a set of conventions, and developers learn them early: flash at the bottom, RAM above it, peripherals higher up. The conventions are useful right up to the point where a family arranges itself differently, and then the tooling — which is built on the conventions — quietly produces output in the wrong shape.

This member of the family is a good example. It has more RAM than its smaller siblings and it distributes that RAM differently, with the result that the address a developer expects to be the start of general-purpose SRAM is actually the start of something with different behaviour entirely.

The map as it actually is

Four regions matter, and they are not interchangeable.

The second row is the one that breaks assumptions. On the smaller members of this family the tightly coupled data memory is 64 KB, and on this one it is 128 KB — which means the general-purpose SRAM starts 128 KB above the base rather than 64 KB above it. A tool told to read half a megabyte starting at the RAM base will read the right bytes and label them with the wrong region names for everything after the first 128 KB.

Why the labelling error survives review

An extraction that mislabels regions still produces plausible output. The bytes are correct, the lengths are correct, and the file opens. What is wrong is the interpretation, and interpretation errors are invisible in a hex dump.

The error surfaces later, usually in one of three ways. A customer tries to relocate a buffer into the region the report called general-purpose SRAM and the transfer stops working, because that region is tightly coupled and not reachable by the DMA engine. A customer builds a linker script from the reported sizes and the image no longer links, because the contiguous span the report implied does not exist. Or a customer compares the recovered RAM image against a memory dump taken with their own tool and finds a 128 KB displacement, concluding that one of the two reads is broken.

The alias at address zero

The instruction tightly coupled memory sits at address zero, and so does the alias of the flash array. Both are reachable at the same address, and which one answers depends on configuration established at reset.

This produces one of the more confusing observations in a live read: a read at a low address returns code before the program has relocated anything, and returns the contents of instruction memory afterwards. Neither reading is wrong. The address is simply served by two different things depending on how the device was set up, and a report that describes it as “the flash base” without qualification is describing only one of the two cases.

The practical rule is to determine the configuration before reading, not after. A boot stage that copies a routine into instruction memory and jumps to it will have left the evidence: a copy loop with a destination in the low address range, a branch afterwards, and the same bytes present twice. Seeing the duplicate is the confirmation that the alias was remapped.

What the linker script tells you

The most compact description of a device’s memory map is the linker script used to build its firmware, and a recovered image usually contains enough of one to reconstruct the intent.

The third row is a useful cross-check on the whole map. The initial stack pointer is the first word of the vector table and it is written by the linker, so it encodes the region the developer chose for the stack. If it lands inside the tightly coupled region, the design deliberately traded DMA reach for speed; if it lands at the top of the general-purpose block, the stack is where the conventions say it should be.

Reading a device that executes from tightly coupled memory

A device with routines in tightly coupled memory presents a specific problem for extraction: the code that matters is not in flash. It was copied there at boot, and the copy exists only while the device is powered.

That means a flash-only recovery returns the source of the copy — which is fine, because the copy is deterministic — but a RAM recovery taken at the wrong moment returns a half-populated region. The window between the copy starting and the jump that follows it is short, and a read taken inside that window contains a mixture of new and old contents that will not reproduce.

The safe approach is to read RAM only after the device has reached a stable state, identified by the program’s own signals: a completed initialisation flag, a steady heartbeat counter, or a peripheral that only runs after startup finishes. Reading early is faster and produces an image that cannot be defended.

What the report should contain

The report should give the map as four named regions with bases and sizes, state which of them are DMA-reachable, and say explicitly which region the stack occupies. It should also note whether anything was executing from tightly coupled memory at the time of the read, because that changes what the RAM image represents.

The banked flash arrangement of the larger members, where the boundary falls in the middle of the array, is covered in STM32F767 firmware recovery. The cache behaviour that decides whether a read of general-purpose SRAM is fresh is in STM32F746 software recovery, and the smallest member of the family, where the same map is compressed into fewer regions, is in STM32F722 code recovery.

FAQ

Is the tightly coupled memory usable as ordinary RAM? It is usable and it is fast, but it is not reachable by the DMA engine, which is the reason designs keep buffers out of it.

Does the 128 KB figure include the instruction memory? No. The two are separate, and the instruction memory is at address zero rather than beside the data memory.

Why does a read at a low address return code? Because the flash array is aliased there at reset, and instruction memory occupies the same address once the device configures it that way.

Conclusion

Four regions, two behaviours and one alias: the map on this part rewards reading the reference manual before reading the device. A flat dump is not wrong, but the labels attached to it decide whether the customer can use it, and the most expensive errors here are the ones that look like correct output.

Comments are closed.