Rescuing An SD Card With An Arduino

A few days ago, one of [Severin]’s SD cards died on him, Instead of trashing the card, he decided to investigate what was actually wrong with the card and ended up recovering most of the data using an Arduino and an immense amount of cleverness.

SD cards can be accessed with two modes. The first is the SDIO mode, which is what cameras, laptops, and other card readers use. The second mode is SPI mode. SPI is slower, but much, much simpler. It turned out the SDIO mode on [Severin]’s card was broken, but accessing it with an Arduino and SPI mode worked. There was finally hope to get files off this damaged card.

[Severin] used a few sketches to dump the data on the SD card to his computer. The first looked at the file system and grabbed a list of files contained on the card. The second iterated over the file system and output all the files in hex over the serial port. With a bit of Python, [Severin] was able to reconstruct a few files that were previously lost forever.

Even though the SD card was completely inaccessible with a normal card reader, [Severin] was able to get a few files off the card. All the sketches and Python scripts are available on the Githubs, ready to recover files from your broken SD cards.

25 thoughts on “Rescuing An SD Card With An Arduino

  1. I wonder what sort of horrible failure mode on the SD card’s controller would leave it in that state. Clearly there is one; but I’m surprised that you could get something as dramatic as losing SDIO (which, while more complex, is definitely the interface that card manufacturers and device makers actually care about and presumably do most of their compatibility testing on) while not trashing the assorted housekeeping measures that the controller uses to isolate you from the ugly details of the raw NAND behind it.

  2. Nicely done but I wonder what brand of SD card he is using for his project is it cheap Chinese or from a well no brand name like sandisk etz. I was thinking will it also on SD card that have the bootloader with software on it from the manufacturer on it sometimes you have to SD cards get boot this software first. But have an SD card not10 years of warranty so you can claim a new one if I’m right but this will not gif back your data so this person found a nice way to bring back the lost data

    1. Yes it would be possible, because whichever mode your using you still have byte level access to the card. The mentioned python script that reads in the hex data probably could be modified to make it dump it to one file.

    2. Yes, but to err on the side of caution: while your recovery tool(s) will probably be accessing non-linearly you run the risk of something else breaking on the already damaged card while (re)reading the card with several tools. Tools such as testdisk/photorec/fdisk/etc can run off an image file just fine (at least in *nix) and not risk angering the card any more that it already has been…

  3. This is a really neat solution. I’m not really into microcontrollers, but I have modified one of my several WRT54GL routers before, reading an SD card over the GPIO pins (SPI bit banging), and it worked. Basically it’s the same thing. The key in a rescue operation like this, be it a failing hard drive or an SD card is to grab as many sectors as possible, then most of the time that file – even though it might have zeroed out blocks – can be mounted over a loop device on Linux, repairing, then accessing the file system almost normally. This eliminates the need to write something that iterates over the list of files, and I’m sure when he finishes duplicating the data, all files will get recovered.

  4. if the problem with the sdio mode is just a corrupt driver or something then you may be able to repair it by getting new driver and re writing it to the card.

    of course it could be the transistors that run the sdio that could be fried or the card maker telling you ok you used this card enough i need some more money so go out and buy a new one.

    1. So what? SD cards are cheap enough and my data valuable enough that once any sort of failure occurs to the card, salvaging the card after some sort of failure is a risk one should avoid. Rescue the data, destroy the card then buy a new one. The bucks you spend on a bigger card is certainly worth avoiding the nightmare of losing data because you were too cheap to buy a fresh card.

      1. I think he was mostly complaining about the tendency of manufacturers to engineer an artificial lifespan into a product, implying that the sd card has some sort of internal counter that makes the card useless when it’s at its predetermined end of life.

  5. The most likely issue with the card is a failure of one of the pins, D1 or D2 (as all others are used for SPI mode). Being able to detect the card and card size, but failing to being able to read the MBR (which contains the partition tables) means the card is failing the first actual data read to memory when in SD bus mode. However, SPI mode and SD bus mode both use the same card registers, state machine, flash interface, and flash controller. So, if he can still do any kind of memory accesses, almost everything has to still be working.

    I would think that using SPI mode to mount the card AND file system, then using some FTP over serial would allow easier recovery of the files versus just mounting the card and bashing the hard way through the file system.

    Also, just as a pet peeve, SD cards typically use SD bus mode, not SDIO. SDIO is an extension of the SD protocol that allows functionality outside of typical memory accesses, such as bluetooth, wifi, or whatever the manufacturer wants to implement. SDIO functions can be used whether the SPI or SD bus electrical interfaces are used.

  6. I think the error of “SDIO mode” as opposed to the correct “SD mode” propagated from the OP’s blog post, as in the original post. Granted, in the OP’s blog post, their “Background” header had a tagline “Attention: Dangerous half-knowledge ahead”.

  7. I had a USB fash drive do the same thing, tried different computers and many data recover programs…Almost gave up… Tried thinking out of the box…and put it in the freezer for 10 mins… plugged it in an WOLA worked long enough to get everything off it :P

    1. I had the same problem once. I had to unsolder the flash chip and read it externally. Thank god most sectors were simply sequential on it (at least the files I wanted, photorec was able to get them from a raw dump) as I had no way of knowing how to read the wear-levelling tables.

  8. Anyone know how to use the parse_files.py? I have the sd_recovery.ino reading the card ok and gibberish is shown in the serial monitor which I assume is the hex data. Ive installed python 2, and use the command “python parse_files.pt test.txt” but it keeps saying AttributeError: ‘NoneType’ object has no attribute ‘group’.

    1. Ok. I used CoolTerm to capture the serial output to a file (make sure use 115200 baud). I edit the output file to remove gibberish at top and the “done!” at the end. In cmd, goto the folder where py file is. Type “python parse_files.py test.txt” and it works better. But it skips them all saying the sizes mismatch. The traceback in python says that nonetype group error again. :(

  9. Only 11 years late to the game… with ESPs now ubiquitous (at 3.3V, so no level shifter needed), I ended up using SPI mode to get the raw image of an otherwise unaccessible SD card (and evtl. browse files) delivered to the PC through an HTTP server (→ no need for Python scripts on the receiving end).
    https://github.com/GiMo84/SDWebRecovery in case you are also desperately trying to get them pesky bytes from your broken SD card.

Leave a Reply to DCCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.