Requests arrive as a purchase order line, a silkscreen, or a note from a purchaser who was told a part number over the phone. Occasionally the number does not exist. It looks plausible, it sits inside a real family, and every character in it follows the naming convention of the parts around it — but the manufacturer does not list it, no data sheet covers it, and no distributor stocks it.

This part number is one of those. The family it claims to belong to is real and well documented; the member it names is not in the catalogue. That does not mean the board in front of the customer is fictional. It means the number describes an intention rather than a device, and the first task is to find out which device the intention turned into.

The problem stated plainly

A recovery cannot start from a name. It starts from a memory map, a protection state and a flash geometry, and all three are properties of a die, not of a label. When the label does not resolve, every one of those properties is unconfirmed, and proceeding on the assumption that the nearest catalogue neighbour is correct is how a job produces a technically clean image of the wrong address space.

The nearby members are similar enough that the mistake survives a long way. They share a core, a package range, a development ecosystem and most of a reference manual. They differ in exactly the things that matter here: how much flash there is, whether there is a display controller, whether there is a crypto block, and where the RAM regions begin.

What the catalogue actually contains

The family line this number imitates has five documented members on the single-core side, and they form a deliberate ladder.

There is no row between 746 and 750 that carries this number, and the ladder explains why: the differentiation in this family is not numerical, it is feature-based. A part one digit away from another is not a slightly faster version of it — it is the same die with a peripheral removed or a block added.

Three readings that settle it

None of these requires removing the lid, and all three are read-only.

The third is the one that resolves the ambiguity a family code cannot. Members of this line share a family code because they share a die; what the code does not tell you is which of the optional blocks were bonded and enabled. A read of a display-controller register that returns a bus fault on a part the customer believes has a display is a decisive answer, and it costs one transaction.

The flash capacity register deserves emphasis because it is the cheapest independent check in the whole job. It answers in kilobytes, it is not affected by protection level, and it disagrees loudly with a wrong assumption. A customer who believes the part has 1 MB and finds a register reporting 64 gets a very different conversation than one who finds 1024.

Why the distinction changes the job

Two examples show how far the consequences reach.

If the part turns out to be the non-graphics member, then a display initialisation sequence found in the image is evidence that the image came from somewhere else — a development build for a different board, a reference firmware, or a previous hardware revision. That is a finding about the customer’s build process, not about the extraction, and it is worth reporting.

If the part turns out to be the value-line member with 64 KB of internal flash, then the job changes shape entirely. A modern application for this class of device does not fit in 64 KB. The internal array holds a boot stage and the real code sits in external memory, and an extraction that stops at the internal array has recovered a loader. The implications of that split are worked through in STM32F750 flash recovery, which is the member this situation actually describes.

The same reasoning governs protection. Crypto-equipped members can hold a key that never appears in the image, because it is loaded into a register and never written to memory. A member without the crypto block cannot do that, so the presence or absence of the block changes what “the image is complete” can possibly mean. STM32F756 code recovery covers that case.

What to do with a purchase order that says this

The third row is the commercially important one. A quotation written against a name that does not resolve is a quotation for an unknown quantity of work, and the difference between the members is not marginal: one of them requires recovering a second memory device that is not on the die.

What the report should say

The report opens with the identification, states which readings established it, and lists what was ruled out. Only then does it describe the memory. A customer who has been told “the part on your board is this one, here is how we know” can correct their own documentation; a customer handed an image with no identification has been given a result they cannot check.

The adjacent reading of the same family from the perspective of the cache rather than the catalogue is in STM32F746 software recovery. The boot-from-ROM path that makes identification matter even more is in STM32F745 heximal extraction, and the smallest member of the line, where a great deal is defined by what is absent, is in STM32F722 code recovery.

FAQ

Does a number that is not in the catalogue mean the part is counterfeit? No. It usually means the number was assembled from a family pattern, or that it is an internal project code. Counterfeits normally carry a real number on a relabelled package, which is a different problem.

Can the package marking settle it? Partly. Marking gives the family and often the flash code and package, but not the enabled options. The register readings are what close the question.

Is it acceptable to proceed on the nearest documented member? Only with the assumption written down and the customer’s agreement, because the work differs in scope between members.

Conclusion

A designation that does not resolve is not a dead end; it is an instruction to identify before extracting. Three read-only register readings — die identification, flash capacity, and a probe for the optional blocks — turn a name into a device, and everything downstream depends on getting that order right. The recovery is only as good as the map it was performed against, and the map begins with knowing which die is on the bench.

Comments are closed.