What happens when two devices share the same SPI bus? With a good design, each device is enabled one at a time for use of the bus, and they coexist without problems. With a bad design, SPI communication that’s intended for one device is sent to the other, leading to confusion and buggy behavior. In the Floppy Emu disk emulator, the SPI bus is shared between an SD card and an LCD display. As it turns out, it had a bug like this that escaped notice for almost two years, with the occasionally flaky behavior wrongly attributed to bad SD cards, faulty boards, or the phase of the moon. Doh!

The symptom was a “No SD card” message, with error code 10:5, when using a few specific models of SD card. During startup, the Floppy Emu firmware was sending SPI commands to the LCD to draw an image, then sending SPI commands to the SD card to initialize it. In rare circumstances, the initial communication with the LCD was confusing the SD card, leaving it in a state where it refused to respond to any further commands until the power was turned off and on. This caused the Emu to think no card was present. The problem didn’t always happen 100% of the time, and it appeared to depend on the electrical characteristics of each board and anything attached to it. But for certain models of SD card, it happened so consistently that the only remedy was to use a different SD card.

My solution was simple: initialize the SD card before doing any LCD communication. Grab the new firmware with the fix here:

floppy-emu-1.0R-F13 – Mac Floppy
hd20-0.7E-F14.5 – Mac Floppy + Hard Disk and Lisa Floppy
apple-II-0.1K-F7 – Apple II, for Model B
apple-II-0.1K-F6 – Apple II, for Model A

 
SPI Mysteries

You might wonder how a problem like this could have gone unnoticed for so long. Looking back over two years of support emails, I only found four problem reports that could be retroactively attributed to this issue. In each case, the person was able to get things working by trying a different SD card, so we chalked up the problem as a damaged or flakey card. It was only recently that I received two reports from people who’d tried multiple cards, all of which failed with the “No SD Card” message and error 10:5. Following up on their hardware, I bought two suspect 16 GB cards (1, 2), and confirmed that they both just plain didn’t work. Ouch. I’ve now verified that the new firmware gets both these SD cards working, and also received confirmation from some other users that the new firmware gets their troublesome cards working too.

So what exactly was the problem? The frustrating answer is that I don’t really know, and my description of the issue intentionally glossed over some important details. It’s true that the LCD communication somehow confused certain SD cards, but I can’t explain why.

Here’s a simplified diagram of Floppy Emu’s SPI bus. The LCD and SD card are independently enabled by separate, active low signals LCDE and SDE. Because the AVR microcontroller operates at 5V, all its outputs are passed through a 74LVC244 buffer to step them down to 3.3V for the LCD and SD card (the 3.3V signal MISO is an output from the SD card, and doesn’t need level conversion). SDE also has a 10K ohm pull-up resistor to +5V, to ensure that the SD card is disabled when the AVR isn’t actively driving the signal, during reset and microcontroller startup.

The only way it should be possible for the SD card to be confused by LCD communication traffic is if SDE were asserted at the wrong time. Looking at the schematic and the firmware code, I just don’t see how that’s possible. The pull-up resistor ensures that the SD card will be enabled if the AVR isn’t actively driving it. And once the AVR does begin actively driving it, it drives SDE high (unasserted) until it’s ready to begin communication with the SD card. So the card should be disabled during the initial LCD communication, and should ignore whatever is happening on the SPI bus.

If I weren’t so lazy, I would put a scope on the SPI bus, and verify that SDE is truly unasserted during LCD communication. But I’m lazy, and didn’t do that.

A few hints point to an electrical problem. With some cards, the 10:5 error occurred more often when I had an AVR programmer attached to the SPI bus, even if the programmer wasn’t active. And with those same cards, seemingly trivial firmware changes would cause the error to appear and disappear. Sometimes I’d only get the error on half my attempts, so it wasn’t a deterministic problem.

Maybe poor circuit design causes a momentary noise spike on SDE, during startup and LCD communication. Ringing, ground bounce, or cross-coupling of signals might cause SDE to briefly appear asserted when it shouldn’t be, causing the SD card to try to interpret communications meant for the LCD. But if that were the case, I’d expect to see all kinds of similar communication errors with the SD card during normal operation.

Another possibility is that there’s something fishy going on with AVR pin PB4, which is also the SPI SS (slave select) pin. The datasheet mentions that there’s some special behavior related to this pin. But after reading that section of the datasheet, I don’t think that’s the cause.

My last theory is that the problem is caused by accidentally switching the SD card into 4-bit mode. SD cards can operate in three different modes: SPI, 1-bit SDIO, or 4-bit SDIO. The latter two modes use the card’s pins like a conventional data bus. I believe the details of 1-bit and 4-bit SDIO may be proprietary and require an NDA, and every hobbyist-made microcontroller project I’ve seen has used SPI instead.

The catch is that SD cards initially power on into 1-bit SDIO mode, and part of the SD card initialization process is to switch to SPI mode, which will remain active until power off. With the old firmware, during the Floppy Emu’s initial LCD communication, the SD card was still in 1-bit SDIO mode rather than SPI mode. I don’t know anything about 1-bit SDIO mode, but maybe the chip select input is used differently in that mode, and my LCD communication was accidentally triggering a switch to 4-bit SDIO mode. As I understand it, once switched to another mode, that mode will remain active until power off, which is consistent with the “zombie SD card” behavior I observed with certain cards under the old firmware. Hmmm…

How much current does a typical USB car charger consume, when nothing is charging? Zero? Microamps? Milliamps? Is it enough to be concerned about draining the car’s battery? There’s no better way to find the answer than direct measurement, so let’s go!

My 2016 Mazda CX-5 has two built-in USB ports, which can theoretically recharge my mobile phone while I’m driving around, but the rate of charge is so slow as to be nearly useless. In an hour of driving, it might raise the phone’s charge level by 15%. To get faster charging, I purchased a USB car charger that fits in the 12V jack in the car’s center console: the ubiquitous jack that was once the cigarette lighter in years gone by, but has now been repurposed as a place to plug in dash cams, DVD players, and other car accessories.

The new USB car charger works fine, and can recharge my phone from zero in about an hour, but it leaves me with a lingering worry. The 12V jack in the 2016 Mazda is not switched by the ignition, but is powered all the time regardless of whether the car is on or off. That means when the car is sitting parked, with the engine off, the USB charger is still drawing current. If I were foolish enough to leave some power-hungry appliance connected, it could quickly drain the car’s battery. But even with nothing connected, the USB charger will still draw some standby current. To measure it, I put together a quick test involving a 12V wall supply, the USB charger, a multimeter, and lots of alligator clips.

The answer: the USB charger’s standby current is 14.2 mA. I would have guessed microamps, so I was way off. It doesn’t help that the charger has an LED that’s continuously illuminated whenever it’s powered.

Is a constant 14.2 mA draw enough to worry about discharging the car’s battery? Probably not. From a few quick searches, I learned that a typical car battery has a capacity of around 40 ampere hours. At 14.2 mA, it would take 2817 hours or 117 days to completely discharge the car’s battery. Assuming I drive the car every day, then, it’s not a concern. Even parking the car for a week or two should be fine. But if I ever need to leave the car in storage for an extended period of time, that 14.2 mA could add up. Of course the car itself has its own standby current draw for the anti-theft system and keyless entry, so the USB charger may not even be the largest concern. For typical driving, at least, it appears the USB charger’s standby current draw won’t be a problem.

While supplies last, the Floppy Emu Model A is on sale at a clearance price of just $79. If you’ve been waiting to add one of these hard disk / floppy disk emulators to your Apple computer collection, now is your chance. The response to the new Model B has been great – maybe a little too great, and I need to close out the remaining inventory of Model A hardware. If you’re a Macintosh or Lisa user, or an Apple IIgs/IIc/IIc+ user looking for a Smartport hard disk, this is a great value! See the compatibility table on the order page and the Model B announcement for more details on Model A vs B differences.

If I were a savvier businessman, I might have waited to introduce the Model B until my inventory of Model A hardware was gone. It’s not quite the Osborne Effect, but introducing a new model that kills demand for the old model may not have been the smartest move. Fortunately for you, my loss is your gain! The good news is that interest in the Model B has been strong. In the past I typically made about one sale per day, but recently it’s been much busier. This was the scene heading to the post office after the 3-day MLK Day weekend:

The Model A is the original Floppy Emu design that’s been featured here at BMOW for over a year. It emulates a classic Macintosh HD20 hard disk or 3.5 inch floppy disk, or a Lisa 3.5 inch floppy disk, or an Apple IIgs/IIc/IIc+ Smartport hard disk, or an Apple IIgs/IIc/IIc+ 5.25 inch floppy disk. Many people have purchased both a Model A and a Model B, to get a dedicated drive for each Apple computer in their collection. Don’t miss this chance to pick up a Model A at a great price!

Today I’m excited to introduce the first significant update to the Floppy Emu disk emulator for Apple II and classic Macintosh computers: Floppy Emu Model B. The new Model B has the same disk emulation functions as the Model A and Universal Adapter, but with several new convenience features:

• Built-in Apple II Compatibility – Model B is directly compatible with the entire Apple II line, emulating a 5 1/4 inch disk, 3 1/2 inch disk, or Smartport hard disk. While Model A required a separate Universal Adapter for the best Apple II compatibility, Model B has the equivalent functionality built-in. Classic Macintosh and Lisa disk emulation is still supported too.
• microSD Card Support – The SD card slot is now a push-push microSD type, identical to what’s used in most mobile phones. This will make it easier to find suitable SD card media, since the older full-size SD cards are becoming rare.
• SD Card Hot-Swap – The SD card can be removed and re-inserted while the Floppy Emu is powered on.
• Improved Protection Circuitry – Model B features improved protection circuitry on the disk drive interface connector. This circuitry will help protect the Floppy Emu from electrical damage caused by voltage spikes and surges. It also eliminates the risk of potential damage if an Emu board running the Apple II firmware is inadvertently connected to a Mac or Lisa computer.
• Same Great Emulation Features – All of the time-tested Macintosh, Apple II, and Lisa disk emulation features from Model A are still present. Model B reads and writes emulated 140K, 400K, 800K, or 1.4MB floppy disk images, or hard disk images up to 2GB, if supported by your Apple computer. For full details, see the instruction manual.

If you’re new to Floppy Emu, it’s an external hardware device for vintage Macintosh, Apple II, or Lisa computers. It uses a removable SD memory card to mimic an Apple floppy disk and drive, or an Apple hard drive. The Emu behaves exactly like a real disk drive, requiring no special software or drivers. Floppy Emu is perfect for booting your favorite games, moving files between modern and vintage machines, and troubleshooting a computer without a working OS. Just plug in the Emu board, and you’ll be up and running in seconds.

Floppy Emu Model B is available for sale now. While supplies last, I’m also selling the remaining inventory of Floppy Emu Model A units for a reduced price. It’s disk emulation madness!