PostHeaderIcon STM32F722: The Family Member Defined by What Is Missing

Marketing material describes microcontrollers by what they include. Recovery work is the other way round: the fastest way to know what you are looking at is to establish what cannot be there. A part that has no display controller cannot be running a display initialisation sequence, and an image that contains one came from somewhere else.

On this member of the family the list of absences is unusually informative, because the die is a deliberate reduction of a larger one. Same core, same instruction set, same development tools, and several blocks removed to make a cheaper part.

What was removed

The reductions are consistent and they cluster around connectivity and graphics.

block present on the larger members present here
Ethernet MAC yes no
display controller yes on most no
graphics accelerator yes on most no
camera interface yes no
flash width 256-bit lines 128-bit lines
instruction and data cache 4 KB or 16 KB each 8 KB each
flash capacity 1 MB or 2 MB 512 KB
general-purpose SRAM 240 KB or 368 KB 176 KB

The last four rows are the ones that matter technically, because they change the shape of the image rather than just its contents. The first four change what a recovery is looking for.

absence what it removes from the job
no Ethernet no network stack, no address configuration stored in flash, no packet buffers to reconstruct
no display controller no timing configuration, no layer descriptors, no frame buffer mapping
no graphics accelerator no asset tables, no colour lookup structures, no blending configuration
no camera interface no image pipeline, and no large double-buffered capture regions

That is a substantial reduction. On the larger members of this family, display and network configuration routinely account for a third of the structured content in an image, and reconstructing it is a large part of the analytical work. Here it is not present, and an image that contains it is not an image of this device.

The narrower flash path

The flash array on this part is read in 128-bit lines rather than the 256-bit lines of the larger members. That single difference has visible consequences.

effect how it appears
code layout functions align to a smaller boundary, so the image looks denser
prefetch behaviour the accelerator in front of the array issues more transactions for the same span of code
a copied routine code relocated into tightly coupled memory shows a 128-bit alignment in the copy loop
an image from a larger member 256-bit alignment in the same places, which is visible and inconsistent

The last row is a practical test rather than a theoretical one. Alignment is not something a compiler randomises; it follows the bus width and the linker’s section placement. An image whose function boundaries consistently align to thirty-two bytes came from a part with a 256-bit path, and finding that on a board labelled as this member means either the label or the image is wrong.

Protection on a part with fewer places to hide

Read-out protection works the same way as on the rest of the family, with the two levels and the same irreversible character at level two. What differs is the number of places data can be concealed.

A part with a display pipeline has external memory, and external memory is a place to store things that are not in the internal array. A part without one usually has no external memory at all, which means everything the product knows is either in the internal flash, in RAM while running, or in a peripheral register. That is a shorter list, and it makes a complete accounting feasible in a way that it is not on a board with three memory devices.

storage location typical contents how it is read
internal flash code, constants, configuration tables direct read
one-time programmable area serial numbers, calibration, sometimes a key direct read, write-once by construction
RAM runtime state, session keys, buffers read with the device halted and the core’s stores settled
option bytes protection state, watchdog behaviour, boot configuration decoded from a read of the option block

The second row is worth checking on every job of this kind, because a one-time area is where a design puts a value it does not want changed, and a recovery that skips it delivers an image without the calibration data that makes the product work. The size is small — around a kilobyte — and reading it is one transaction.

What the smaller cache does to a live read

Eight kilobytes of data cache is small enough that a running program evicts constantly, which is fortunate for extraction: the window in which a dirty line sits unwritten is shorter than on the larger members, so a probe read is more likely to be current. It is not a guarantee, and the procedure is the same — halt, settle the stores, read — but the failure rate is lower.

The cache behaviour itself is described in STM32F746 software recovery, which deals with the larger cache and the same underlying problem. A worked case on this exact part number, where the firmware was encrypted and the recovery had to establish that the plaintext was already in flash, is at STM32F722RET6 firmware restoration — the two pages address different questions about the same die and are worth reading together.

When the absences do not match

The most useful outcome of this line of reasoning is a contradiction found early. Three checks, each taking a minute.

First, look for a display initialisation sequence: a block of writes to consecutive registers with timing values that resolve to a plausible horizontal and vertical total. If it is there, the part is not what the label says, or the image is not from this board.

Second, look for a network stack: a byte-order-sensitive header parser, a set of buffers with a fixed maximum size, and an address structure in flash. If it is there, the same conclusion follows.

Third, check the flash size register and compare it with the capacity the image implies. An image that fills more than half a megabyte cannot have come from a device with a half-megabyte array.

finding conclusion
no display, no network, 512 KB consistent with this member
display configuration present the image came from a graphics member, or from a development build
network stack present the image came from a member with Ethernet
image larger than the array the file includes padding, or the read included a region that is not flash

What the deliverable looks like

The report should state the identification and the evidence for it, including the absences checked. It should give the flash image with its length and the erased tail distinguished from programmed content. It should give the one-time area and the option bytes as separate small files, because they are small, they are independently useful, and bundling them into a single blob makes them easy to lose.

The identification discipline itself, for the case where the name on the order does not resolve at all, is in STM32F747 binary recovery. The boot-from-ROM path that remains available when the flash cannot be read normally is in STM32F745 heximal extraction, and the USB side of a device in this class, which is often the only external interface it has, is in STM32F723 binary recovery.

FAQ

Does the missing display controller mean the product has no display? Not necessarily. A display can be driven by an external controller over a serial or parallel interface, in which case the interface configuration is in the image instead of a display pipeline.

Is the smaller cache a disadvantage for extraction? It is an advantage, because dirty lines are evicted sooner. The procedure is unchanged.

Can an image from a larger member run here? It will not fit, and its alignment gives it away before anyone tries.

Conclusion

Absence is evidence. On this member the removed blocks define both the identity of the device and the scope of the work: no display pipeline to reconstruct, no network stack to map, a shorter list of places data can hide, and a flash path whose alignment betrays an image from elsewhere. Establishing what cannot be present is faster than confirming what can.

Comments are closed.