In 2018, only 3% of the data on a USB flash drive was accessible at all. Soon after, the flash drive became entirely unrecognizable to the computer.
That USB stick I got in 2016 had 32 GB, and both USB-A and USB-B Micro OTG endings, for desktop and mobile respectively, by the vendor Hama, whose flash storage notoriously is of low quality despite of similar prices. For simplicity, I will refer to it as "Hama2016" in this post.
Due to my terrible experiences with Hama (these total failures, and short integrity retention spans), I have not purchased any of their flash storage since at least 2017.
When I found it somewhere in early 2018 after at least half a year of non-usage, I plugged it into my computer. A flash drive was detected, but it was unresponsive indefinitely. When opening it, Windows Explorer's placebo loading bar (shared inside folder path bar) never hit the end, and just kept loading, even after I let it load for ten minutes when I was away from the computer.
The scan
I then plugged it in again and tried scanning it for bad blocks and lost files using IsoBuster. The Hama USB stick's controller does not report bad blocks to the computer, but I still wanted to see what happens.
It scanned for a while, getting stuck intermittedly for few seconds but then continuing. At around 3%, it became unresponsive indefinitely, i.e. until removed. Upon retry, the same happened. And when trying to access any logical block address (LBA) that is located beyond the first 3% using a Hex editor, it also becomes unresponsive indefinitely.
The readable 3% contained some JPEG thumbnails. Those I've seen were undamaged.
Soon after, Hama2016 got a "USB device not recognized" error.
Possible causes
The USB port of my Grundig RRCD 3720 boombox is the main suspect, as an all-in-one memory card reader by ISY (similar to this one) connected to it in early 2017 stopped working around that time ("USB device not recognized", but memory cards read through it are fully functional. (Side note: The Grundig RRCD 3720 has an integrated SD card slot, but it does not support SD-XC, only up to SD-HC.)
It is possible that I connected Hama2016 to the RRCD 3720's USB port somewhen in 2017.
When the RRCD 3720 starts in USB mode (out of USB/SD/CD/Radio/Tape, not necessarily in this order; starts with mode selected at last poweroff), the USB port is powered on for approximately a quarter second, then powered off for a second, and then powered on as usual.
I don't know whether this short quarter second power-on period might have caused the damage. I have used other USB sticks on that boombox by the vendors Intenso, SanDisk, and XLyne, and they work fine.
The USB port might also have outputted a voltage spike, which the USB stick by HAMA didn't survive due to inferior circuitry compared to that of other vendors. I don't own tools to detect a voltage spike yet, but will post here when I have.
The reason I have this suspicion is that in mid-2020, another flash drive, also a double-sided USB-A+USB-OTG by Hama, but with 16 GB, from 2015 (the same as in this post that lost data within months), hence "Hama2015" for this post, stopped working imminently after connected to the RRCD 3720. However, I frequently connected Hama2015 to the RRCD 3720 in 2017, and it always worked. But since that time in mid-2020, when connecting it to the computer, it detects the USB stick as a memory card reader with no card inserted ("Please insert a disk into Removable Disk (H:)"). In comparison, the 32 GB HAMA from above (Hama2016) is not detected at all, and the computer shows a "USB device not recognized" error. But a common cause is possible.
Between the time 3% of Hama2016 were readable and it being completely unrecognizable, I can't remember whether I plugged it into the RRCD 3720, but it is possible.
Linux has not reacted to both Hama2015 and Hama2016 at all. Possibly some "dmesg" errors were caused, but I have not taken a look at them yet.
The RRCD 3720's integrated power supply is a linear transformer (SMPS would interfere with AM radio) which converts 230V MAINS to around 12V, but the USB port's intended 5V power is likely delivered through a switching regulator / buck converter. It is possible that it lets through an overvoltage for a very short moment, which would be p**s-poor design. Another possible cause for a voltage spike is failure of a voltage-damping capacitor somewhere in the RRCD 3720, though I would have to take it apart to find out.
What are your thoughts on this? And had any of you have a similar experience?
I probably have stored most data from Hama2016 somewhere else, but to be sure, how could it be repaired?
What are your thoughts on this? And had any of you have a similar experience?
I probably have stored most data from Hama2016 somewhere else, but to be sure, how could it be repaired?
There is nothing "strange" (unless by "strange" you actually mean "common enough").
Flash drives (more generally electronic devices) fail, sometimes often, sometimes seldom, but they do fail.
Not necessarily the Grundig thingy you have is the culprit (and not necessarily an under or over voltage or anyway an electrical spike).
They fail basically because they (and the devices to which they are connected) are poorly designed, poorly manufactured, poorly used (this latter in the sense that there can be other factors, like static electricity, and or dirt, humidity and what not when handling them, that are independent from the quality of the project, board, components).
In a USB stick there are basically:
1) 1 or more flash chips (these rarely fail)
2) a quartz or similar component for frequency timing (at least in the early models)
3) a controller (usually manufactured by a known or obscure company in China anyway with little or no documentation/datasheet/pinout/tools)
4) a few (or many) different surface mounted elementary components, such as resistors, capacitors, etc.
5) several (usually poorly made) solderings for the above components on a (as well usually bad quality) circuit board
What can go wrong?
EVERYTHING in the list above (+1).
What fails?
ANYTHING in the list above may fail (though - usually - the flash memory chip in itself - unless "worn down" is the least likely to).
To this you add that almost all such devices (with a known exception that is SanDisk, but there may be more brands/makes that do the same, that use a proprietary sort of JTAG to program the chip/controller) make settings for these controllers via (usually undocumented) serial commands through the same USB bus, so there is a concrete risk that a "programming sequence" is sent to the device because of *any* issue in the OS, software, driver, *whatever*.
The device CANNOT be repaired (or more exactly, it simply makes no sense to attempt to repair it), unless it is only a "mechanical" kind of problem, i.e. a bad soldering visible or anyway traceable with instruments OR IF it is actually working and can be re-programmed/reset via (if available) a specific "manufacturer's tool", i.e. it is a software/firmware issue only and in this latter case not necessarily the data can be recovered, the device can be "repaired" in the sense of "reset to factory but data is gone.
BUT (in some cases, but not always) recovering the data on the device can be done.
This usually involves EITHER of:
1) procure an identical surely working device (much easier to say than doing it in practice, due to the insane number of models and revisions, both in production and out of production) and transplant to it the memory chip.
2) do a chip-off (or on some models find a JTAG or similar "direct" access points) and then transfer and "decode" the data from the flash with external software (as opposed to using the controller on the procured identical device).
Example:
jaclaz
Thanks alot for the thorough post.
What fails?
ANYTHING in the list above may fail (though - usually - the flash memory chip in itself - unless "worn down" is the least likely to).
But what possibly explains that the first 3% of the storage were readable for a while?
Addition to:
It scanned for a while, getting stuck intermittedly for few seconds but then continuing. At around 3%, it became unresponsive indefinitely, […]
When I ran said scan, another thought I had is that Hama2016's flash controller might be poorly programmed to lock up intentionally due to a read timeout. But that would contradict with the possibly similar controller of Hama2015, which just returned logically damaged data, but fought through it at around 100 to 500 KB/s rather than the usual approximate 20 MB/s on logically undamaged parts. So this already suggested that something was physically wrong with Hama2016.
If a flash drive fails, one would expect the entire thing to become defunct, like has happened with Hama2015 after plugged into the RRCD 3720 in mid-2020.
So how possibly come three percent were temporarily readable on Hama2016?
Think of a malfunctioning (not dead, only malfunctioning) component, let's say the quartz (if any).
When cold it works, then as soon as the thingy warms up a little bit (it takes approximately the time needed to read 3% of the device to get to 43.7 C°) it stops working.
Or a cold soldering.
Or ...
jaclaz
Â
as soon as the thingy warms up a little bit (it takes approximately the time needed to read 3% of the device to get to 43.7 C°) it stops working.
When I did try to access any LBA beyond 3% imminently after plugging it in, it also got stuck indefinitely. If this alone were the issue, it would stop earlier when read for a second time (as described in the first post), as it already is heat up when starting the second reading attempt.
Or a cold soldering.
If one of the memory chip's solder pin disintegrated, as far as my understanding goes, that part of the memory might be inaccessible entirely. Maybe the stick was dropped on rough ground at some point, but not that I remember.
That 3% readability error might have a different cause than the complete undetectability that followed afterwards. But yes, flash memory indeed has delicate components prone to error.
Heat damage might also have contributed to it. In 2011, a smartphone's internal storage disappeared entirely after it became hot. But that might be a different cause, such as a crash that caused a FAT32 error, causing the mobile phone to be unable to mount it, while the device was still able to boot, and I don't think the OS storage (<500 MB) and the user storage (around 16 GB) are stored on two separate memory chips. Back then, the smartphone's internal storage (separate from system partition) needed to have a common file system for compatibility, whereas now, it is done through MTP, and smartphone operating systems presumably are equipped with software to repair file system errors anyway.
Â
Yep, more generally, the whole idea of rare, random, intermittent faults is that they are:
1) intermittent
2) rare
3) random or semi-random
4) not easily reproducible
and more than that, apart known failures that affect hundreds or thousands of a given make/model in the same manner, EACH and EVERY such faults is likely to be a case on its own.
jaclaz
