The 100-pin member of the F435 family adds the one thing the 64-pin part cannot: room for the external memory interface. Two QSPI ports, an XMC controller that speaks SDRAM, SRAM, PSRAM, NOR and NAND, and a parallel camera interface all need pins, and this is the package that has them. For a recovery that changes the question from “what is in the flash” to “what is in the product”.
A Second Code Space
QSPI is not just storage on this part. It supports address-mapped mode, which means code can execute directly from an external SPI flash device as though it were internal. A design that does this puts its bootloader in the internal array and its application — or a large part of it — in an eight-pin package next to the MCU.
No read of the internal array will produce that code. It is worth saying plainly, because it is the most common gap between what a customer expects from a recovery and what the die can give.
What The Internal Read Still Covers
The internal array holds what the design needed to be fast or what it needed to survive a missing external part: the startup code, the clock and pin configuration, the external memory controller setup itself, the update logic and, usually, the keys or the checksum seeds used to validate what sits outside.
That is not a consolation prize. The code that configures the QSPI controller tells us the external part’s address map, its read command and its size, which is exactly what a technician needs to read the external device separately.
XMC And The 8080 Mode
The same controller can drive a parallel LCD in 8080 or 6800 mode, and the pins overlap with the memory interface. On a board with a display, the visible bus activity is often display traffic, and the memory chip — if there is one — may be idle during the capture. Distinguishing the two from the pin patterns alone is unreliable; the firmware’s own register writes are the better guide, which is another reason the internal image is worth having first.
DVP Pins That Look Like Memory
The camera interface brings eight to fourteen data lines plus synchronisation into the same package. On a device with a camera, the DVP bus can dominate the pin activity. Nothing about that traffic helps a read, and treating it as a memory bus produces a false picture of what the part is doing.
Protection Covers The Die Only
The protection mechanisms are the family standard: whole-array access protection, per-sector erase and program protection, and sLib with a sector-aligned password-protected range. The array is a megabyte, sectors are 4 KB, and the second 512 KB sits behind its own register pair. None of that says anything about the external memory.
An external QSPI flash is usually unprotected. That asymmetry — a locked die next to an open serial flash — is what makes some of these designs recoverable at all, and it is worth flagging to the customer before the job starts, because it determines the budget.
Scoping A Job With External Memory
Three questions decide the plan: is there a QSPI device on the board, is XMC connected to anything, and does the product boot with the external part removed. The third is the decisive one. If it boots without it, the internal array is self-sufficient. If it does not, the external device holds code or critical data and has to be read as part of the job.
Deliverables
From the die: a megabyte image in two bank halves plus a merged file, the configuration byte that sets the SRAM split, and a sector map. From the external device, if present: a separate binary with its own read report. The two are delivered together with a note on which addresses the controller maps where, reconstructed from the register writes in the startup code.
The 64-pin version without the external bus is at hacking secured AT32F435RGT7 firmware. If your product keeps its data in a battery-backed device rather than flash, the retention and readout issues are covered in extracting NVRAM content from an IC. The mid-range part with a parallel LCD interface is at dumping secured AT32F423VCT7 flash memory. Ask about a specific board through contact.