EmbeddedRelated.com
Forums

SD CARDS

Started by Onestone February 8, 2012
Again I don't think that explains why it works for some cards, well the
first 2 cards I tried it with, but not for others. this suggests that
the pashing is correct, unless people have implemented different phasing
on their brand. But thats easily checked, and no cigar! (my spi init
code has all 4 options with the unused 3 commented out, it saves typing
when moving code between different devices).

Cheers

Al

On 11/02/2012 1:48 AM, Redd, Emmett R wrote:
> Sometimes SPI can be a bugger too. There are 4 different possibilities between the phasing of the bits and the clock. The old Motorola 68HC11 'Pink' book has good timing diagrams (8-1&2 in the copy on my lap). If the SD card documentation is sketchy/limited that timing could cause big problems even if all the pull-ups are in place.
>
> HTH
>
> Emmett Redd, Ph.D., Professor mailto:E...@MissouriState.Edu
> Physics, Astronomy, and Materials Science Office: 417-836-5221
> Missouri State University Dept: 417-838-5131
> 901 S NATIONAL AVENUE FAX: 417-836-6226
> SPRINGFIELD, MO 65897 USA Lab: 417-836-3770
>
> It is clear that thought is not free if the profession of certain opinions make it impossible to earn a living. -- Bertrand Russel
>> -----Original Message-----
>> From: m... [mailto:m...] On Behalf
>> Of Paul Curtis
>> Sent: Friday, February 10, 2012 9:12 AM
>> To: m...
>> Subject: RE: [msp430] RE: Re: SD CARDS
>>
>>> I couldn't find it in hurry, but I'm fairly certain that one of the
>>> many documents I've read over the last few days stated that SPi
>>> support was mandatory as part of the SD card spec, and that document
>>> was discussing
>> the
>>> 2.x physical spec
>> I'll dig up the exact reference tonight. As far as I recall, I have
>> all SD specifications and the addendums, and somewhere it notes that
>> for microSD cards, specifically, that SPI mode is an option.
>>
>> If there is no response to CMD0, then the card believes it should be in
>> SD mode, and refuses to enter SPI mode.
>>
>> --
>> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
>> SolderCore running Defender... http://www.vimeo.com/25709426
>>

Beginning Microcontrollers with the MSP430

Hi,

> Right, but why would an unitiialised card do that? it simply powers up and
the
> first thing it sees after the power up delay is CMD0, which is designed to
> force SPI mode if received when CS is low, and I've confirmed that CS is
low.

Not from my reading of the spec:

"The SD Card is powered up in the SD mode. It will enter SPI mode if the CS
signal is asserted (negative) during the reception of the reset command
(CMD0). If the card recognizes that the SD mode is required it will not
respond to the command and remain in the SD mode. If SPI mode is required,
the card will switch to SPI and respond with the SPI mode R1 response."

I think the "If the card recognizes that the SD mode is required it will not
respond to the command and remain in the SD mode" happens to be what you're
seeing. For whatever reason, the SD card thinks it should remain in SD mode
and you don't get a R1 response.

I have seen a wide range of deviations in cards in SPI mode--I am assuming
cards don't get tested in SPI mode all that often or very thoroughly. The
Kingston cards I have come from a range of dice suppliers. There are some
cards that are particularly problematic from no-name manufacturers.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore running Defender... http://www.vimeo.com/25709426

I guess that depends on interpretation. I take

It will enter SPI mode if the CS
signal is asserted (negative) during the reception of the reset command
(CMD0).

To mean that it WILL enter SPi mode, not that it may decide not to,
otherwise the spec should read "will enter SPI mode if the internal
logic does not detect a need to stay in SD mode".

I think the requirement for Sd mode or SPI mode is determined by the
condition of the CS pin during receipt of the CMD0 reset command, since
the final two sentences allow for the either SD or SPI mode being
required. I know this is semantics, worse than the sort of weasel words
that lawyers use, but, to me at least, the plain English interpretation
is that this point enforces either SD mode OR SPI mode based solely on
the state of the CS pin during CMD0, and, of course, to some degree the
correct initialisation delays before issuing any commands.

Thanks to everyone who has chimed in to help. It seems that SD in SPI
mode is not reliable, and for just 25 units I sure don't want to pay a
fee to licence SD mode, so I'll just have to either find a card that
works as is, or figure out what the problem is. I still think it is
related to pull-ups, but can't test that until I can solder some onto
the existing (cramped) board.

Cheers

Al
On 11/02/2012 2:54 AM, Paul Curtis wrote:
> Hi,
>
>> Right, but why would an unitiialised card do that? it simply powers up and
> the
>> first thing it sees after the power up delay is CMD0, which is designed to
>> force SPI mode if received when CS is low, and I've confirmed that CS is
> low.
>
> Not from my reading of the spec:
>
> "The SD Card is powered up in the SD mode. It will enter SPI mode if the CS
> signal is asserted (negative) during the reception of the reset command
> (CMD0). If the card recognizes that the SD mode is required it will not
> respond to the command and remain in the SD mode. If SPI mode is required,
> the card will switch to SPI and respond with the SPI mode R1 response."
>
> I think the "If the card recognizes that the SD mode is required it will not
> respond to the command and remain in the SD mode" happens to be what you're
> seeing. For whatever reason, the SD card thinks it should remain in SD mode
> and you don't get a R1 response.
>
> I have seen a wide range of deviations in cards in SPI mode--I am assuming
> cards don't get tested in SPI mode all that often or very thoroughly. The
> Kingston cards I have come from a range of dice suppliers. There are some
> cards that are particularly problematic from no-name manufacturers.
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> SolderCore running Defender... http://www.vimeo.com/25709426
>
>
On 10 Feb 2012, at 13:46, Matthias Weingart wrote:

> "Paul Curtis" :
>
>> microSD cards are not required to support legacy SPI mode. The ones I have
>>
> Hi Paul,
>
> Is your information from a official document? According to wikipedia, SPI is
> optional for MMC, but MicroSD have a "yes" in the table (bottom of page):
> http://en.wikipedia.org/wiki/SD_Memory_Card#Technical_explanation

At one point, Wikipedia believed the same as me. Perhaps I read it on Wikipedia:

http://en.wikipedia.org/w/index.php?title=Secure_Digital&diffA2862593&oldidA2855668

No microSD card I have has actually failed to function in SPI mode, but the no-name cards are somewhat problematic. Sandisk cards have been perfect, but not always the fastest. Speed class in SPI mode is not specified, of course, and all SD cards need to be treated as class 0 in SPI mode. Real shame that, but I guess I understand the reasons.

-- Paul.

On 10 Feb 2012, at 20:28, Onestone wrote:

> Thanks to everyone who has chimed in to help. It seems that SD in SPI
> mode is not reliable, and for just 25 units I sure don't want to pay a
> fee to licence SD mode, so I'll just have to either find a card that
> works as is, or figure out what the problem is. I still think it is
> related to pull-ups, but can't test that until I can solder some onto
> the existing (cramped) board.

You could always get a TI dev kit that has microSD all connected up and test your card in that. The MSP-EXP430F5529, for instance.

http://www.ti.com/tool/msp-exp430f5529

-- Paul.

Paul Curtis :

>
> On 10 Feb 2012, at 13:46, Matthias Weingart wrote:
>
>> "Paul Curtis" :
>>
>>> microSD cards are not required to support legacy SPI mode. The ones I
>>> have
>>>
>> Hi Paul,
>>
>> Is your information from a official document? According to wikipedia,
>> SPI is optional for MMC, but MicroSD have a "yes" in the table (bottom
>> of page):
>> http://en.wikipedia.org/wiki/SD_Memory_Card#Technical_explanation
>
> At one point, Wikipedia believed the same as me. Perhaps I read it on
> Wikipedia:
>
> http://en.wikipedia.org/w/index.php?title=Secure_Digital&diffA2862593&o
> ldidA2855668
>
> No microSD card I have has actually failed to function in SPI mode, but
> the no-name cards are somewhat problematic. Sandisk cards have been
> perfect, but not always the fastest. Speed class in SPI mode is not
> specified, of course, and all SD cards need to be treated as class 0 in
> SPI mode. Real shame that, but I guess I understand the reasons.

Thx Paul,

during a websearch (on mostly german pages) I read several comments from
hackers, that they encounter into the same problem: no response to CMD0 on
some Micro-SD cards.

Matthias

Hi Matthias,

> > At one point, Wikipedia believed the same as me. Perhaps I read it on
> > Wikipedia:
> >
> > http://en.wikipedia.org/w/index.php?title=Secure_Digital&diff=41286259
> > 3&o
> > ldid=412855668
> >
> > No microSD card I have has actually failed to function in SPI mode,
> > but the no-name cards are somewhat problematic. Sandisk cards have
> > been perfect, but not always the fastest. Speed class in SPI mode is
> > not specified, of course, and all SD cards need to be treated as class
> > 0 in SPI mode. Real shame that, but I guess I understand the reasons.
>
> Thx Paul,
>
> during a websearch (on mostly german pages) I read several comments from
> hackers, that they encounter into the same problem: no response to CMD0 on
> some Micro-SD cards.

Fair comment; I have a large collection of cards, but I haven't added any
microSD cards recently. Perhaps it's time to get a new batch of cards and
see what we can see. :-)

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore running Defender... http://www.vimeo.com/25709426

Reginald Beardsley :

> Footnote on p 21 of:
>
> http://www.flashgenie.net/img/productmanualsdcardv2.2final.pdf
>
> states that pins 8 & 9, which are reserved in SPI mode must be pulled up
> in addition to lines 1, 2 & 7

This is a newer document from SanDisk:
http://www.altec-computersysteme.com/downloads/Produkte/Flash_Speicherkarten
/SD_Cards_miniSD_microSD/SanDisk_SD_Card_Family_PM_v2.2.pdf

In the document there is a pin assignment for MicroSD in SPI-Mode, and there
is _NO_ comment that SPI-Mode is not implemented in MicroSD. However it is
from 2007; maybe Sandisk have changed their policy now.

This is from this sandisk document on page 3-2, foot note for the SD Bus
Mode Pin Assignment (maybe this is not true for SPI mode, because this pins
are marked "reserved" in SPI-Mode.):
"It is the responsibility of the host designer to connect external pullup
resistors to all data lines even if only DAT0 is to be used. Otherwise, non-
expected high current consumption may occur due to the floating inputs of
DAT1 & DAT2 (in case they are not used)."

Another footnote: for DAT3 Pin:
"At power up this line has a 50KOhm pullup enabled in the card. This resistor
serves two functions:
Card detection and Mode Selection. For Mode Selection, the host can drive the
line high or let it be pulled high to select SD mode. If the host wants to
select SPI mode it should drive the line low. For Card detection, the host
detects that the line is pulled high. This pull-up should be disconnected by
the user, during regular data transfer, with SET_CLR_CARD_DETECT (ACMD42)
command."

M.

"Paul Curtis" :

>> Thx Paul,
>>
>> during a websearch (on mostly german pages) I read several comments from
>> hackers, that they encounter into the same problem: no response to CMD0 o
> n
>> some Micro-SD cards.
>
> Fair comment; I have a large collection of cards, but I haven't added any
> microSD cards recently. Perhaps it's time to get a new batch of cards and
> see what we can see. :-)

Mee too: several old cards (including MMC, and half MMC cards and SDHC) but
only a few MicroSD's - all of them are working in SPI-mode. I was able to get
all cards working in SPI-Mode (but some of them need special treatment, e.g.
up to 1sec and several CMD0 during initialisation).
However there are some "no name" cards that have memory faults, and after
several writes do not work anymore. Since this time I only buy SandDisk cards
- no problems at all yet.

Matthias

The link would not allow me access :-( Could we collect this stuff in the files folder?

--- On Sat, 2/11/12, Matthias Weingart wrote:

> From: Matthias Weingart
> Subject: [msp430] Re: SD CARDS
> To: m...
> Date: Saturday, February 11, 2012, 4:12 AM
> Reginald Beardsley :
>
> > Footnote on p 21 of:
> >
> > http://www.flashgenie.net/img/productmanualsdcardv2.2final.pdf
> >
> > states that pins 8 & 9, which are reserved in SPI
> mode must be pulled up
> > in addition to lines 1, 2 & 7
>
> This is a newer document from SanDisk:
> http://www.altec-computersysteme.com/downloads/Produkte/Flash_Speicherkarten
> /SD_Cards_miniSD_microSD/SanDisk_SD_Card_Family_PM_v2.2.pdf
>
> In the document there is a pin assignment for MicroSD in
> SPI-Mode, and there
> is _NO_ comment that SPI-Mode is not implemented in MicroSD.
> However it is
> from 2007; maybe Sandisk have changed their policy now.
>
> This is from this sandisk document on page 3-2, foot
> note for the SD Bus
> Mode Pin Assignment (maybe this is not true for SPI mode,
> because this pins
> are marked "reserved" in SPI-Mode.):
> "It is the responsibility of the host designer to connect
> external pullup
> resistors to all data lines even if only DAT0 is to be used.
> Otherwise, non-
> expected high current consumption may occur due to the
> floating inputs of
> DAT1 & DAT2 (in case they are not used)."
>
> Another footnote: for DAT3 Pin:
> "At power up this line has a 50KOhm pullup enabled in the
> card. This resistor
> serves two functions:
> Card detection and Mode Selection. For Mode Selection, the
> host can drive the
> line high or let it be pulled high to select SD mode. If the
> host wants to
> select SPI mode it should drive the line low. For Card
> detection, the host
> detects that the line is pulled high. This pull-up should be
> disconnected by
> the user, during regular data transfer, with
> SET_CLR_CARD_DETECT (ACMD42)
> command."
>
> M.
>
>
>
>
>
>
>
>