3 ms·

I would love to see pictures of the testing / analysis rig, etc. That would be very interesting.

• pkaye 11y ago
  Its from a company I no longer work at. Not much really to it. The hardest part is connecting to the NAND. We had special debug connections provisioned to make it easy. Other options include desolder the part and putting into a socket, using a interposer, using boundary scan. Then we had a FPGA board that connected to the NAND and via USB to a PC. The FPGA board issued the proper signal patterns to control the NAND and the PC had a GUI interface to issue all kinds of commands to the NAND including doing a raw read and write to files. Obviously we cannot decrypt anything stored on NAND. When we get a failed SSD, I would read the internal logs and try to root cause it. Sometimes, we have to power up the firmware or change contents of the NAND to help determine the root cause and the concern is the problem is no longer reproducible. By keeping a backup, I have a good chance of recovering things back to the original state. Having a backup gives me lots of freedom to experiment. I've seen weird multi-factor failures where a batch of NAND parts would fail due to high temperature, with particular data pattern written using specific commands. One of those things that even manufacturing screening could catch in reasonable time. Debugging these failures was always one of those moments where I would go in wondering "what the heck is going on" to ... "ah now it makes sense."