Flash and SSD · bench notes · HUL-2025-0918
It Stopped Saving First, Then It Stopped Altogether.
A history group in Driffield had the lot on one stick: parish registers photographed page by page, old show catalogues, and the recollections of older residents, typed up one winter at a time. The failure came in a particular order. In March the machine they use at meetings would not take anything new
. By June folders were refusing to open. Now the only answer left is USB device not recognized
.
Sounds like yours? Ring us.
0800 6890668
What causes it.
The order the symptoms arrived in is the whole story. Writing is what wears flash out; reading does not. Each program-and-erase cycle costs a cell a fraction of its life, and a read costs it nothing at all. So saves failing in March, then access failing in June, is what a spent stick looks like. While spare blocks last, the controller retires the tired ones without telling anyone, and keeps its translation tables on cells it still trusts. Once the spares are gone the tables go as well, and the stick stops replying on the bus. The message on screen is describing a controller that has fallen silent. It has nothing to say about the scans.
The tools this one needed.
The steps we follow →| The gear | What this one did | Why we have it |
|---|---|---|
| PC-3000 Flash | Matched the NAND against its library, then read the chip off the board | Goes round the controller and reads the NAND itself, matched to a maker-ID library kept current |
| Rusolut Visual NAND Reconstructor | Lifted the XOR mask and returned the pages to the order the dead controller had kept | Makes sense of a raw NAND dump: ECC, XOR, page order, then reassembly |
| R-Studio Technician | Rebuilt the FAT volume, which brought the volunteers' own file names back with it | Handles almost any file system, and puts RAID sets back together |
The stages.
Which had failed: the memory or the controller
There was no response at all over USB, so the case came off and probes went onto the board. Asked directly, the memory answered immediately and gave a part number we already had on file. Next to it the controller stayed quiet. The sequence the fault had followed — saves, then reads — had already suggested as much.
Take the pages first, work out the order later
What comes off a chip is not yet a disk image. Every page carries its error-correction bytes, sits behind an XOR mask of the controller's choosing, and lands in an order set by a translation layer that has gone. Correct the errors. Strip the mask. Restore the order. Do all three and files start to exist; do two of the three and nothing does.
Rebuild the volume, then open every file
Once corrected and resequenced, the FAT tables read cleanly again and the archive appeared under the names the group had given it. The checking was manual, one item after another: registers, catalogues, the typed interviews. Totals mean very little here. A file that refuses to open has not come back.
How it finished.
Everything went back out on fresh media. A rule has gone into the group's own minutes since: three copies, and one of the three kept off the premises. The spent stick sits in a drawer as a reminder of the order it went in.
What people read after this.
More on SSD & flash.
Is yours doing the same?
Turn it off. Send it to us. The diagnosis comes first. It says which files are still readable and which are not.