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.