Damaged chip recovery is feasible whenever the silicon memory array survives — even if the package is cracked, the pins are snapped off, or the host board is destroyed. The deciding factor is not how badly the board looks, but where the damage sits relative to the flash cells and the protection logic guarding them. A charred QFN with an intact die can still yield a complete firmware image; a part that looks perfect but has been electrically overstressed may yield nothing.
That distinction carries commercial weight. A discontinued controller or legacy production board often holds the only copy of its firmware on one damaged unit. Whether that copy is still readable — and how far a lab must escalate to reach it — decides cost and downtime.
Damage Type Sets Feasibility, Not Severity
| Damage observed | What is affected | Outlook |
|---|---|---|
| Snapped pins, broken leads (DIP/QFP) | Package and leadframe only | High |
| Corrosion on the board, die intact | Traces, pads, solder joints | Moderate–high |
| Water ingress, shipped unpowered | Board, plus creeping corrosion | Moderate–high |
| ESD or overvoltage on I/O pins | Possibly the memory array | Variable |
| Crack through the memory region | The memory cells | Unrecoverable |
| Triggered anti-tamper wipe | Data erased by design | None |
Five Signals a Lab Checks Before Quoting
- Power-up behaviour. Does the die draw plausible current, or is it shorted and dead?
- Debug port response. A part that enumerates on SWD but returns zeros differs from one that never answers.
- Die-level inspection. Optical and X-ray checks for cracks, corrosion and broken bond pads.
- Damage geometry. How close the corrosion or crack runs to the memory array and protection block.
- A reference unit. A second working board separates damage from design in a comparative read.
What You Actually Get Back
Physical damage usually means the part is not returned in working order. The deliverable is the data and its documentation:
- Raw image as
.bin,.hexor.s19 - An address map showing code, configuration and calibration regions
- A checksum report plus a read-consistency check
- Recovered option bytes, fuses and protection state, plus a note on damaged regions
Why a Dead Board Is Not a Dead Chip
Board-level failures cluster in the hardest-working circuits — power regulation, motor drivers, high-current outputs. Flash arrays are quiet by comparison and frequently survive the event that killed everything around them. That is why the escalation order matters: try an in-circuit read, then a bootloader path, then IC decapsulation and direct probing. Escalate only as far as the data requires, because every step consumes samples — and protection does not vanish because a chip is damaged, so check how MCU readout protection levels constrain what any lab can attempt.
Legality and Handling Discipline
Recovery should only be attempted on hardware you own or are authorised in writing to service, under NDA — the same boundary that governs any chip recovery engagement. Three rules protect your chances: stop powering a wet board, do not repeat failed flash attempts, and ship in anti-static packaging with a second sample.
FAQ
Can firmware be recovered from a water-damaged board?
Often yes, but corrosion is time-sensitive. Ship it promptly and unpowered; expect the read to happen at chip level once the surrounding electronics are cleaned or bypassed.
Does the chip survive damaged chip recovery?
Not usually. Semi-invasive and invasive work opens the package, so plan to program the recovered image onto a fresh, identical part.
How do I know recovery is possible before committing budget?
Ask for a feasibility assessment first: a credible lab states the damage class, the realistic method, and an honest “not feasible” when that is the answer.
Often yes, but corrosion is time-sensitive. Ship it promptly and unpowered; expect the read to happen at chip level once the surrounding electronics are cleaned or bypassed.
Does the chip survive damaged chip recovery?
Not usually. Semi-invasive and invasive work opens the package, so plan to program the recovered image onto a fresh, identical part.
How do I know recovery is possible before committing budget?
Ask for a feasibility assessment first: a credible lab states the damage class, the realistic method, and an honest “not feasible” when that is the answer.
Send the Damage Details
Photograph the board, note the chip marking and package, and describe what happened. We will tell you which damage class your part falls into, the realistic method, and whether recovery is worth it — request a free assessment before you spend anything.