I'm working on a USB flash drive that has a little physical damage on the connector, but no other visible problems. It reports to be 0MB or uninitialised and no data can be read from the OS.

Controller Vendor: SMI
Controller Part-Number: SM3267AC - ISP 160128-1AC
Flash ID code: AD3A18A3 - Hynix H27UDG8M2MTR - 2CE/Single Channel [TLC-16K] -> Total Capacity = 32GB

It's a double sided board with the controller and one NAND on one side, and the other NAND on the other side. They are TSSOP and QFN parts which for me makes reflow work a lot easier than BGA, so I can take them off to read them externally (I'd have to get a reader for that). But before I'm going the hardware route, I'm wondering if the SMI controller has some sort of recovery mode or raw-read mode.

There are a number of MPTools from SMI that have debug portions that allow different kinds of access to the NAND, RAM, controller settings etc. but haven't spotted a raw-NAND-read option. It does get detected properly (including the NAND, so that's good, but I'm not sure how to safely check NAND command availability using MPTool as it's obviously intended for manufacturing testing and loading of preset images. I tried the udisk creation option which is supposed to create a low-level image for mass production, but that resulted in 32GB of nulls.

There is a bad block counter that's set to 99, but 97 of those are 'normal' reserved bad block entries, code 80, which appears to not refer to actual bad blocks.
There are two entries in the bad block list that refer to something else:

New Bad Block : 2
=== >>>>> ===================================================================================================
New Block Index: 0, Block: 82, Page: 49, ErrorCode: 3
New Block Index: 1, Block: 86, Page: 3D, ErrorCode: 3
=== <<<<< ===================================================================================================

Other than that, the PCB and none of the chips get warm, the LED does light up but doesn't blink (probably because there is no normal FTL activity).

I could start with some simple voltage probing to see if maybe some traces have micro fractures, but perhaps someone here knows of other software controlled testing/reading options for the SMI controllers?

Unless you have experience (and even then) I would advise against MPtools use. the fastest way to send nand blank again. These tools have poor manuals, if at all and often translated badly. I am leaning towards firmware issues in the controller.

These can have good results with chip-off, relatively easy for DR lab.

unlikely to be electronic component, but you could check I guess. If you wanted to buy a reader, the soft center one is a little over US$200, and you could outsource dumps, or get Soft Center to recover for I think US$217

Or if you want to start data recovery, buy a full DR kit with support such as VNR

I soldered the WP pins on both NAND chips to enable write protect so the controller couldn't wipe them even if it wanted to. I guess I'll just dump the NAND. It looks like it is using static XOR for storage, but I'll probably want to spend my time on something else and just outsource the dump processing.

Edit: thinking of another nice hack: how about getting an identical USB drive and swapping the controller (or both NANDs). Or I could upload a fresh firmware to the drive, see what that gets me. On the other hand: a lot of risky work and time which I might as well spend on something else.

Yes, the time it would take to go through a few possibilities, and the increased risk may not be worth it inmost cases.

Granted, some like to work on a problem as a project, and I have seen some really interesting ones.

if you swapped, you would need to swap both controller and NANDs. in manufacture stage, the controller is setup with nands using the MP tools. Not sure how the XOR is actually set, I am guesing either in the controller mem itself, or firmware, but I have seen exact same controller numbers with different XOR, different data/SA areas (layouts), different ECC etc. The PCB would likely need to be exactly the same as well.

These are WL chips, and also contain a bad column file, or software bad columns

I did export the settings, configuration area (which appear to be different things) and bad sector data, and I even found the same firmware BIN, but I don't think I'm going to risk a bad controller-NAND match. The weird thing is that it's almost as if the controller can't talk to the NAND, but since it can ID them (which uses the same data lines AFAIK?) you'd think that can't be it. Or perhaps the firmware is faking it and just stores the flash ID and reports that back when queried.

Almost certainly the flash memory has degraded to such a level that the controller cannot correct the bit errors, hence being able to ID the NAND but not access it properly.

So no amount of soldering, replacing components or chip transplants will fix that.

You’ll need something like VNR, PC3000 Flash or Flash Extractor hardware and software or preferably all 3 to get a result on this type of device and failure. Even then, it won’t be easy.

Assuming you actually want the data, I’m 99% certain you are wasting your time tinkering with it, and possibly making things worse or even unrecoverable

_________________
PC Image Data Recovery
http://www.pcimage.co.uk

New!! HDD-PCB.COM for all your PCB and donor HDD requirements!