I did some spring cleaning today. My apartment is all sparkly now. At least I got something accomplished this weekend, after going into work to get caught up on some things only to discover that my workstation, which was working just fine at about 6:30 PM on Friday, would no longer pass its power-on self-test on Saturday morning at about 10:00 AM. Perhaps just a sign that I wasn’t supposed to do work this weekend.

Yesterday evening, I started the last bit of assembly of my new balanced β22 headphone amplifier, which meant disassembling my existing one. I’ve been putting it off since I wanted to have minimal downtime without the amp.

There’s a whole lot of wiring that goes into a big amp. The whole task of assembling the enclosures and wiring up the boards inside of them is at least as much work as putting the boards themselves together.

As I was wiring up the power connections, I wanted to check the polarity of a few wires to make sure I had hooked them up correctly. Unfortunately, I wasn’t mindful of the fact that I had just stripped a set of power supply wires in preparation for soldering them to another amplifier board. The ends of these wires were floating around loose in the box. As I was probing at the wires I wanted to test, the end of one of the wires made contact with part of the circuit and made sparks.

For the record, shorting the 30V rail on a power supply whose outputs are not current-limited to the high-current output stage of an amplifier board (at 0V) is not a great idea.

I ended up frying both power supply boards, and one of the amplifier boards. I’d be hard-pressed to come up with another two points on the circuit to short together to more efficiently damage so many parts at once.

I located and fixed the problems with the power supplies, but the amplifier board is going to take some more careful diagnosis. It’s hard to isolate the faults (and the evidence suggests that there are multiple faults) without applying power to the board, which on a damaged board can cause other components to be operating outside of their tolerable ranges. The resistor pictured above let out its magic smoke after overheating this morning.

Fortunately, the weather outside is absolutely gorgeous and I’m able to open my window to air out the pervasive odor of smoked resistor without letting all of the warm air out.

SD Data Recovery via SPI, originally uploaded by orderedpixels.

Despite the fact that I’m usually pretty good about keeping everything backed up¹, 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 disk², 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 converter³. 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!

1. in multiple places! [↩]
2. does anyone still remember these? [↩]
3. Let me know when these show up on the shelves at your local Fry’s next to the USB-to-PS/2 and USB-to-serial converters. [↩]