The Raven Deconstructed
March 18th, 2009 by Brian
CSE 466 final project presentation in the CSE building atrium tomorrow morning. The project specification is here.

CSE 466 final project presentation in the CSE building atrium tomorrow morning. The project specification is here.
Despite the fact that I’m usually pretty good about keeping everything backed up1, there are still some things that slip through the cracks. In this case, I had an SD card with a few files that I was actively working on. SD cards and flash drives are convenient to move files between multiple machines–just plug in the card and there are your files; it doesn’t matter which computer you’re using. Unfortunately, while they’re perhaps more reliable than the 3.5″ floppy disk2, they’re not infallible.
The aforementioned card worked fine for several years, until it suddenly developed an interesting problem. It still worked, but thought that it was only 8MB, when in fact it was a 1GB card. That, of course, meant that the filesystem was no longer usable and most of the important data on the card were gone. I tried it in multiple different readers and devices, all with the same result.
I had written it off for a while, tossed it in a desk drawer, and accepted the data loss. And then I had an interesting idea.
In addition to the “native” SD data mode, SD cards also support an interface called SPI, or Serial Peripheral Interface. SPI is a fairly simple four-wire serial protocol that’s used on a lot of microcontrollers and embedded devices. SPI support on SD cards exists specifically to make them easily accessible from a low-cost microcontroller without any specialized hardware. I wondered whether perhaps while the card’s controller chip was rather confused, that maybe if I accessed the data a block at a time over SPI, it would all still be there. Maybe the controller would quietly ignore the fact that I was asking for blocks that were beyond the new reported capacity of the device.
FTDI makes a really neat line of USB-to-serial converter chips, which I’ve used extensively. One of them, the FT2232, in addition to the standard RS-232 serial port features a neat little widget known as the Multi-Protocol Synchronous Serial Engine, which basically allows one to implement a USB-to-any-arbitrary-synchronous-serial-protocol converter3. It happens to work great for USB-to-SPI.
To make a long story short and cut out more technical details that 98% of my readers probably won’t understand anyway, a few minutes later, I had an SD card plugged into a breadboard with an FT2232 module and a makeshift voltage regulator, and a few wires to connect it up. I wrote a quick, hacky program, and got the card to power up and respond to commands. Crossing my fingers, I read off the first block of the card, opened it up in a hex editor, and sure enough, saw filesystem headers. Crossing my fingers again, I tried reading a block that was beyond the first 8MB that I could access normally. It worked! I could access any block on the entire card in this manner!
359 lines of C code, 77 minutes and 37.326 seconds of transferring later, I had a complete disk image of the entire 1GB card, with all of my data intact. Yay!
:set sarcasm
Who made the brilliant decision that Windows should automatically instantly reboot when it encounters a kernel error/blue screen of death? Many sites out on the internet (and Microsoft’s own support database, I’m sure) will gladly tell you how to go into the Control Panel and disable this “feature.” That doesn’t help much with a machine that won’t boot because it keeps bluescreening. The information in the error message may be cryptic, but it’s at least some info and can sometimes point to a driver or setting that’s causing the problem. Sometimes it would be nice to look at it for more than a millisecond.
Seriously, do people really find it more comforting when their computer just spontaneously reboots, with no indication that something went wrong, rather than display an error message that at least lets the user know that there was a problem of some sort?