ST72F321AR Secured Memory: What Changes When the Work Goes Physical
There is a moment in every protected-device job when the socket stops being useful. The session is refused, the read returns nothing meaningful, and the only remaining question is whether the contents matter enough to open the package. ST72F321AR secured memory work begins at exactly that moment, and it is a different discipline from everything that preceded it.
Different tools, different failure modes, a different relationship with the sample. The most important difference is the last one: everything up to that point is reversible, and nothing after it is.
The moment the socket stops being enough
Three conditions push a job from a session to a die. The read returns a uniform value because protection is active. The part has no session-based read path at all because its memory is masked. The part responds but the response is unstable in a way that no amount of timing adjustment fixes.
| condition | what a session gives you | why it stops |
|---|---|---|
| protection active | a uniform read | the array is not disclosed through the interface |
| masked memory | nothing | there is no programmable array to address |
| unstable session | partial or corrupt data | the transport is marginal and cannot be improved |
| damaged device | nothing | the part does not run, so it cannot answer |
The fourth condition is the one worth arguing about before opening anything. A device that does not run may still have a perfect array, and the physical route will recover it. It may also be a device whose failure is in the array itself, in which case the route recovers nothing and the sample is gone. Establishing which by putting the part back in a functional board is cheaper than any amount of preparation.
What the package actually is
The part is a die bonded into a leadframe and encapsulated in an opaque epoxy. The die is small — a few square millimetres for a device of this class — and it sits face-up, wire-bonded to the leadframe, with its active surface covered by a passivation layer and, above that, by the mould compound.
Everything the recovery wants is in the top few micrometres of that stack. The flash array’s floating gates, the ROM implant pattern, the metal routing that reveals where the blocks are — all of it is within reach of an optical instrument once the material above it is removed.
The removal is the destructive part. There is no process that opens a plastic package and leaves it usable as a component, which is why the decision to go physical is a decision about the sample and not about the technique.
Three routes to the die, three different risks
The routes differ in how much of the package is removed and how much control is needed over what remains.
| route | what it preserves | main risk | suitable when |
|---|---|---|---|
| full decapsulation from the top | the whole die surface | damage to the array from the opening process | optical read of a masked array |
| local opening over the array | the rest of the package and the bonds | positioning error | a single region is needed |
| backside access through the substrate | the front-side metal | thinning control | front-side metal blocks the view |
For a device of this generation, the first route is usually correct, because the process node is old enough that the array is legible from the front and the metal stack is thin enough not to obscure it.
Why an older process node helps
The parts in this family were fabricated on processes with few metal layers and comparatively large features. Both facts work in favour of the recovery.
Fewer metal layers means less to remove before the array is visible, and less chance of bending a layer during removal. Larger features mean the array cells are resolvable with ordinary optical magnification rather than requiring an electron microscope, and it means the implant pattern of a masked array is distinguishable by contrast rather than by inference.
| property of the node | effect on the work |
|---|---|
| two to four metal layers | the array is reached with modest material removal |
| feature size in the sub-micron but not deep-sub-micron range | optical resolution is sufficient |
| single polysilicon floating gate | the programmed state is a visible contrast difference |
| mask ROM implemented as implant or contact presence | readable as a pattern, not as a charge |
That last row is the reason masked parts are recoverable at all. A flash cell stores charge, which changes a threshold and is inferred electrically. A masked cell stores geometry, which is visible.
Reading the array, and what “reading” means here
Once the surface is exposed, the work becomes imaging and reconstruction rather than protocol. The array is photographed at sufficient magnification to resolve individual cells, the images are stitched into a map, and the cell states are converted into bits according to the encoding the array uses.
The reconstruction is where the preparation pays off. Without a known memory map, the stitched image is a picture of a grid. With a known map — where the application region begins, where the vector table sits, what the reset handler should look like — the bits can be placed at addresses and validated immediately.
That validation is the only quality control the physical route offers. There is no read status, no checksum returned by the device, and no second attempt. If the reconstructed image has a plausible vector table with every entry landing inside the application region, the read is probably good. If it does not, the image has to be re-examined before it is delivered.
What you lose by going physical
Four things, and each one changes what the customer can do with the result.
The sample is gone, so no second opinion is possible on the same unit. The array may be partially damaged by the opening, so some bits may be ambiguous rather than wrong. The device’s own self-verification is unavailable, so completeness has to be argued from structure. And the timing is measured in days rather than hours, because each step has to be done carefully and inspected before the next.
| property | session read | physical read |
|---|---|---|
| sample survives | yes | no |
| verification source | the device’s own responses | structure and consistency |
| typical turnaround | hours | days |
| failure recovery | retry with better parameters | re-examine images, or accept |
| result confidence | high if the session is stable | depends on image quality |
The decision that should come first
Before any of this, one question decides whether the work is worth doing: what will the customer do with the contents?
If the answer is “repair units in the field”, the recovery has to produce a programmable image plus a method of getting it into replacement parts, and that is a different deliverable from a raw binary. If the answer is “understand what the product does”, a functional map is worth more than a bit-exact image. If the answer is “verify that a competitor copied our design”, the comparison is structural and does not need every byte.
Each answer points at a different stopping point, and going past it consumes samples for nothing. “Repair units in the field” in particular implies more than an image: it implies that the recovered firmware will actually run in a replacement part, which is not automatic and is examined in ST72F325K4 flash program cloning. The same discipline applies on flash parts whose session is still open: the three-outcome classification in ST72F32AK1 flash memory protection exists precisely so that the physical route is chosen deliberately rather than by default. Where the ambiguity is about memory technology rather than protection, ST72F321J9 flash memory settles it without opening anything.
What a physical result looks like
The deliverable from a die-level recovery is a package of artefacts: the reconstructed image with a declared base address, an image of the die surface for reference, a statement of which regions were legible and which were ambiguous, and the vector table used to validate the reconstruction.
The ambiguity statement is not a hedge. It is the most useful part of the report, because it tells the customer which parts of their firmware are certain and which are inferred, and it lets them decide whether the certainty is sufficient for the purpose they had in mind.