SD card SPI a bad idea?

Hi folks-

My HW/SW design team is deep into the design cycle of a consumer device 
that has a micro SD card socket.  We chose SPI communication instead of 
SDIO.  The choice has mostly worked but we're starting to have regrets 
because a small percentage of SD cards we've seen will not function 
correctly when used with SPI.  We have a handful of competing products 
that read the failing cards and have found that none of them use SPI. 
That gives me some doubt about our choice.

Has anybody out there been down this same path but instead chose SDIO 
over SPI because of SPI compatibility problems?

Thanks - John

On Thu, 19 Feb 2015 11:03:53 -0800, John Speth wrote:

> Hi folks-
> 
> My HW/SW design team is deep into the design cycle of a consumer device
> that has a micro SD card socket.  We chose SPI communication instead of
> SDIO.  The choice has mostly worked but we're starting to have regrets
> because a small percentage of SD cards we've seen will not function
> correctly when used with SPI.  We have a handful of competing products
> that read the failing cards and have found that none of them use SPI.
> That gives me some doubt about our choice.
> 
> Has anybody out there been down this same path but instead chose SDIO
> over SPI because of SPI compatibility problems?
> 
> Thanks - John

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.

-- 
www.wescottdesign.com

On Thu, 19 Feb 2015 11:03:53 -0800, John Speth <johnspeth@yahoo.com>
wrote:

>My HW/SW design team is deep into the design cycle of a consumer device 
>that has a micro SD card socket.  We chose SPI communication instead of 
>SDIO.  The choice has mostly worked but we're starting to have regrets 
>because a small percentage of SD cards we've seen will not function 
>correctly when used with SPI.

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
1 bit mode is an adequate solution.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

On 2/19/2015 1:10 PM, Tim Wescott wrote:
> On Thu, 19 Feb 2015 11:03:53 -0800, John Speth wrote:
>
>> Hi folks-
>>
>> My HW/SW design team is deep into the design cycle of a consumer device
>> that has a micro SD card socket.  We chose SPI communication instead of
>> SDIO.  The choice has mostly worked but we're starting to have regrets
>> because a small percentage of SD cards we've seen will not function
>> correctly when used with SPI.  We have a handful of competing products
>> that read the failing cards and have found that none of them use SPI.
>> That gives me some doubt about our choice.
>>
>> Has anybody out there been down this same path but instead chose SDIO
>> over SPI because of SPI compatibility problems?
>>
>> Thanks - John
>
> Bummer.  That's good to know.  Are you sure that you are conforming to
> all necessary pull ups, downs, speeds, etc.?

Yes, triple checked.

> 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.

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

> 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 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

On 2/19/2015 3:33 PM, Stephen Pelc wrote:
> On Thu, 19 Feb 2015 11:03:53 -0800, John Speth <johnspeth@yahoo.com>
> wrote:
>
>> My HW/SW design team is deep into the design cycle of a consumer device
>> that has a micro SD card socket.  We chose SPI communication instead of
>> SDIO.  The choice has mostly worked but we're starting to have regrets
>> because a small percentage of SD cards we've seen will not function
>> correctly when used with SPI.
>
> 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
> 1 bit mode is an adequate solution.

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

Un bel giorno John Speth digit�:

> Has anybody out there been down this same path but instead chose SDIO 
> over SPI because of SPI compatibility problems?

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.

-- 
Fletto i muscoli e sono nel vuoto.

On Fri, 20 Feb 2015 09:49:22 -0800, John Speth wrote:

> On 2/19/2015 1:10 PM, Tim Wescott wrote:
> 
> I've delivered that message already.  Management is penny wise and pound
> foolish.

Well, not in this thread.

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

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

John Speth <johnspeth@yahoo.com> writes:
> Has anybody out there been down this same path but instead chose SDIO
> over SPI because of SPI compatibility problems?

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.:

  http://www.bunniestudios.com/blog/?page_id=1022

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

Paul Rubin <no.email@nospam.invalid> wrote:
> John Speth <johnspeth@yahoo.com> writes:
> > Has anybody out there been down this same path but instead chose SDIO
> > over SPI because of SPI compatibility problems?
> 
> 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.:

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

On 2015-02-20 John Speth wrote in comp.arch.embedded:
> On 2/19/2015 1:10 PM, Tim Wescott wrote:
>> On Thu, 19 Feb 2015 11:03:53 -0800, John Speth wrote:
>>
>>> Hi folks-
>>>
>>> My HW/SW design team is deep into the design cycle of a consumer device
>>> that has a micro SD card socket.  We chose SPI communication instead of
>>> SDIO.  The choice has mostly worked but we're starting to have regrets
>>> because a small percentage of SD cards we've seen will not function
>>> correctly when used with SPI.  We have a handful of competing products
>>> that read the failing cards and have found that none of them use SPI.
>>> That gives me some doubt about our choice.
>>>
>>> Has anybody out there been down this same path but instead chose SDIO
>>> over SPI because of SPI compatibility problems?
>>>
>>> Thanks - John
>>
>> Bummer.  That's good to know.  Are you sure that you are conforming to
>> all necessary pull ups, downs, speeds, etc.?
>
> Yes, triple checked.

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.


-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

Cheer Up!  Things are getting worse at a slower rate.