On 2/24/2015 2:11 AM, Stef wrote:> 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.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
SD card SPI a bad idea?
Started by ●February 19, 2015
Reply by ●February 24, 20152015-02-24
Reply by ●February 25, 20152015-02-25
In article <mc5c2n$fp$1@speranza.aioe.org>, johnspeth@yahoo.com says...> 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 >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
Reply by ●February 25, 20152015-02-25
On Tue, 24 Feb 2015 12:37:04 -0800, John Speth wrote:> On 2/24/2015 2:11 AM, Stef wrote: >> On 2015-02-20 John Speth wrote in comp.arch.embedded: >>> >>> [snip] >>> >>> 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. > > 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. > > JJSSo - and this is important - did you solve the problem? Do random SD cards work now? Was it a clock issue?
Reply by ●February 25, 20152015-02-25
In article <mcll7v$an2$1@speranza.aioe.org>, akuktin@gmail.com says...> On Tue, 24 Feb 2015 12:37:04 -0800, John Speth wrote: > > > On 2/24/2015 2:11 AM, Stef wrote: > >> On 2015-02-20 John Speth wrote in comp.arch.embedded: > >>> > >>> [snip] > >>> > >>> 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. > > > > 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 > > 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?
Reply by ●February 26, 20152015-02-26
> 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.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
Reply by ●April 4, 20152015-04-04
On Fri, 20 Feb 2015 09:49:22 -0800, John Speth <johnspeth@yahoo.com> wrote:>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 > > >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 -- John Larkin Highland Technology, Inc picosecond timing laser drivers and controllers jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
