SD card SPI a bad idea?

Bummer. That's good to know. Are you sure that you are conforming to all necessary pull ups, downs, speeds, etc.?

It would seem that for a consumer device the production volume would be large enough to pay for the licensing and extra work to put SDIO into service.

This note is good for me, because I'm working on a personal project that'll use SD cards. My installed base is going to be small enough that I can get away with dictating what cards are used, but it's still good to know that some will work and some won't.

I am told (but have no proof) that in the latest round of SD specifications, the SPI mode is no longer required. We have used 1 bit SD mode on some devices and it seems to work faster than SPI. If you hardware has an SD peripheral, using it in

Stephen

Yes, triple checked.

I've delivered that message already. Management is penny wise and pound foolish.

I need to say that my regrets are more a gut feeling based on the occasional bad experience with some cards. The problems could be the cards only. They're dirt cheap, possibly sorting dropouts, many non-branded, and I suspect not appropriate for the application (audio playback streaming).

Funny thing, I have a non-branded card. There is a marking on the cardboard packaging indicating that tech support is available but there is no tel number, web site, or source information anywhere.

JJS

Thanks for that hint. I did a little googling and found statements on both sides of the fence (SPI will be optional or mandatory in the future). This SD card biz is the wild west.

JJS

I'd be more worried about the performances. Native SDIO is 4 to 16 times faster than SPI, depending on how many data lines you use.

Well, not in this thread.

"Penny Wise" is a good name for a manager of corporate cost control.

We used SPI in a thing I worked on a while back, and occasionally got cards or batches that didn't work. Consumer SD cards are very inconsistent and generally crap and sometimes branding is fake--you might look at some of Bunnie Huang's articles about them, e.g.:

It's possible industrial cards (Transcend Industrial e.g.) are better. Of course they cost more.

I think that's the take-home. I helped out with debugging SDIO drivers on the Raspberry Pi (for RISC OS, which doesn't use a Linux kernel) and there were and are similar kinds of issues. The Linux kernel has a big pile of 'quirk' handling - some for the SDHCI controller and some for the card. Essentially you end up reimplementing this quirk support in your own driver.

A headache with SDIO is you have to deal with multiple clocks and multiple signalling voltages - the driver is a fair bit more complex than SPI mode. (Though you can limit those if you don't need higher speeds).

I suspect stuff gets tested on Windows and Linux/Android and then shipped without further testing. Though I'm slightly surprised that the USB readers generally work as well as they do. Possibly the chip vendors have paid for verification suites which the rest haven't, I don't know.

Theo

Als make sure you provide enough clocks for the card to recognise level changes of \CS (and in other places as well). A long time ago we used some code that had been working on a DSP that kept the clock going in between SPI transfers and ported that to a controller that only runs the clock during the transfer and it stopped working. Inserting a few dummy bytes (giving an additional 8 clocks) solved the problems in that case. IIRC the problem caused some cards to work and others not and the difference was not obvious from the datasheets.

Yep, that was one of the first things that dragged me into a few days of head scratching when I started my project. I stumbled upon the exact same solution just by shotgunning luck.

JJS

I can verify that this is true. I have found, through extensive testing, that only SanDisk cards work in SPI mode reliably, across the board. I have several cards that flat out will fail CMD16, which is supposed to be required to call yourself an SDHC card. I am seriously thinking about going to the 4 bit SD mode and paying the royalty. For now, I can force the customer to use the supplied card and you can get a pretty good deal on bulk SanDisk cards on various websites. BTW, so far I have found that SanDisk, and Patriot seem to be reliable in SPI mode. About the only brand I have not tested yet is Panasonic.

Jim

So - and this is important - did you solve the problem? Do random SD cards work now? Was it a clock issue?

I can tell you certainty that it is hit and miss if a manufacturer actually supports SPI mode correctly. SanDisk still fully supports SPI mode and Patriot seems to also. Those have been the only two that the SDHC cards actually work reliably in SPI mode. In the future I am just going to bite the bullet and use the true SD mode and pay the royalty. I think that is what they are trying to do anyway. When a card fails to support an SPI command that is considered mandatory for it to be called an SDHC capable card, but only in SPI mode. What more is there to say?

These words truly show that you've paid your dues. I'm almost there. The keywords here are "reliably" and "correctly". My experience is the bad actors in SPI mode are highly variable in reliability (will eventually fail the same way every time) or have incorrect responses (simply do not support certain commands or my favorite: the all zeros error token).

JJS

There are apparently a goodly number of faked SD cards being sold, like 1GByte cards that report themselves as being 64G. Even on Amazon, apparently.

Google H2testw