Hi Paul, and thanks, I don't hold MOSI high, but I do send FF as the
data, both before, and dring 'wait' clocks. I have managed to get other
cards working, sometimes. ie when I pull a card and change it, or
disturb it in any way i lose the ability to communictae, sometimes, but
not always. So it's looking like I have some PCB assembly issues as well
as card troubles, yet for some reason the Nokia card soldiers on
regardless. I have had a micrometer on it, and it is marginally thicker
across the contacts than the other brands I have, but not enough to be
out of spec. Similarly the other cards are all in spec. So I still hate
SD cards. I think I have a combination of some obscure timing/sync
issues and mechanical issues with the PCB. I have a new design coming
through and have an SD card option on it, so I may solve the mechancial
issues with that card. I hope so.

I will try holding MOSI high as a digital I/O rather than a data line,
and send the clock manually, or (I have never tried this) just set P3SEL
for SCLK, and see if that allows me to send clocks only without sending
data., can't see how it will work thinking on it, but will try anyway.

Cheers

Al

On 12/03/2012 9:07 PM, Paul wrote:
>> 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 did some more work on figuring out which cards may or may not respond to going into SPI mode.
>
> According to section 6.4.1 of the simplified spec v3.01, to enter SPI mode requires that CMD (MOSI) be high when issuing deselected clocks to the card and before issing CMD0. If I force CMD0 low and issue 74 clocks, some cards will enter SPI mode regardless and some will not enter SPI mode.
>
> Just something to consider--when issuing the clocks, make sure that MOSI is high.
>
> Regards,
>
> -- Paul.
>

Beginning Microcontrollers with the MSP430

> 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 did some more work on figuring out which cards may or may not respond to going into SPI mode.

According to section 6.4.1 of the simplified spec v3.01, to enter SPI mode requires that CMD (MOSI) be high when issuing deselected clocks to the card and before issing CMD0. If I force CMD0 low and issue 74 clocks, some cards will enter SPI mode regardless and some will not enter SPI mode.

Just something to consider--when issuing the clocks, make sure that MOSI is high.

Regards,

-- Paul.

Good to hear that some extra effort may have helped then. And
yes, I see your point.

Thanks,
Jon

On Tue, 14 Feb 2012 00:46:34 +1030, you wrote:

>Hi Jon, well I started reading the 900 page document, and immediately
>came across this, which clarifies (to me) something that Paul raised, ie
>the selection of SD/SPI may not happen if the card determines it needs
>Sd when you have sent a reste cmd with CS asserted:-
>
>/3 . 1 B u s T o p o l o g y
>The SD Memory Card system defines two alternative communication
>protocols: SD and SPI. Applications
>can choose either one of modes. Mode selection is transparent to the
>host. The card automatically
>detects the mode of the reset command and will expect all further
>communication to be in
>the same communication mode. Therefore, applications which uses only one
>communication mode
>do not have to be aware of the other./
>
>I think this makes it clear that the /CS-CMD0 route should always force
>SPi mode.
>
>Here's something else I was unable to find elsewhere. I had
>somedifficulty figuring byte ortder in the 4 byte CMd argument, since it
>seems that all data stored on the card is in little endian format. To me
>it seemed obvious that if the card stores LE then it should be addressed
>LE. Normally this wouldn't be an issue, since if one failed I'd sim ply
>swap, but it got worse when I also couldn't find anything that told me
>the addressing was byte linear not sector based, since my first round of
>limited documentation ONLy used SEcTORS and BLOCKS (an unexpected name
>change for the SECTOR). anyway this clarifies the data storage situation:-
>/
>1.5.2 Numerical values in two-byte fields
>A numerical value in a two-byte field shall be recorded in the little
>endian representation. It shall be recorded
>according to ISO/IEC 9293.
>1.5.3 Numerical values in four-byte fields
>A numerical value in a four-byte field shall be recorded in the little
>endian representation. It shall be recorded
>according to ISO/IEC 9293.
>
>Cheers
>
>Al

Hi Jon, well I started reading the 900 page document, and immediately
came across this, which clarifies (to me) something that Paul raised, ie
the selection of SD/SPI may not happen if the card determines it needs
Sd when you have sent a reste cmd with CS asserted:-

/3 . 1 B u s T o p o l o g y
The SD Memory Card system defines two alternative communication
protocols: SD and SPI. Applications
can choose either one of modes. Mode selection is transparent to the
host. The card automatically
detects the mode of the reset command and will expect all further
communication to be in
the same communication mode. Therefore, applications which uses only one
communication mode
do not have to be aware of the other./

I think this makes it clear that the /CS-CMD0 route should always force
SPi mode.

Here's something else I was unable to find elsewhere. I had
somedifficulty figuring byte ortder in the 4 byte CMd argument, since it
seems that all data stored on the card is in little endian format. To me
it seemed obvious that if the card stores LE then it should be addressed
LE. Normally this wouldn't be an issue, since if one failed I'd sim ply
swap, but it got worse when I also couldn't find anything that told me
the addressing was byte linear not sector based, since my first round of
limited documentation ONLy used SEcTORS and BLOCKS (an unexpected name
change for the SECTOR). anyway this clarifies the data storage situation:-
/
1.5.2 Numerical values in two-byte fields
A numerical value in a two-byte field shall be recorded in the little
endian representation. It shall be recorded
according to ISO/IEC 9293.
1.5.3 Numerical values in four-byte fields
A numerical value in a four-byte field shall be recorded in the little
endian representation. It shall be recorded
according to ISO/IEC 9293.

Cheers

Al

/On 13/02/2012 11:16 PM, Jon Kirwan wrote:
> If you uncover anything interesting in the documents worth a
> mention, please feel free. I'm curious about what you are
> going through and anything you find that relates to this.
>
> Thanks in advance,
> Jon
>
> On Sun, 12 Feb 2012 18:37:48 +1030, you wrote:
>
>> Hi Jon, thanks for all that. I hunted around for a long time and could
>> only find the rather limited 'simplified' specs, plus a few odd papers
> >from individual card manufacturers. I think this is what misled me into
>> thinking nthe Micro SD interface was different to the SD spec. In
>> addition other replies (I think David) have cited that they were able to
>> operate Micro SD with a single pull up, whereas I have 3 (CS and the 2
>> RSV reserved lines). I'll go and collect these docs and have agood read
>> before I go much further.
>>
>> Cheers
>>
>> Al
>
>

If you uncover anything interesting in the documents worth a
mention, please feel free. I'm curious about what you are
going through and anything you find that relates to this.

Thanks in advance,
Jon

On Sun, 12 Feb 2012 18:37:48 +1030, you wrote:

>Hi Jon, thanks for all that. I hunted around for a long time and could
>only find the rather limited 'simplified' specs, plus a few odd papers
>from individual card manufacturers. I think this is what misled me into
>thinking nthe Micro SD interface was different to the SD spec. In
>addition other replies (I think David) have cited that they were able to
>operate Micro SD with a single pull up, whereas I have 3 (CS and the 2
>RSV reserved lines). I'll go and collect these docs and have agood read
>before I go much further.
>
>Cheers
>
>Al

Hi Jon, thanks for all that. I hunted around for a long time and could
only find the rather limited 'simplified' specs, plus a few odd papers
from individual card manufacturers. I think this is what misled me into
thinking nthe Micro SD interface was different to the SD spec. In
addition other replies (I think David) have cited that they were able to
operate Micro SD with a single pull up, whereas I have 3 (CS and the 2
RSV reserved lines). I'll go and collect these docs and have agood read
before I go much further.

Cheers

Al

On 12/02/2012 12:49 PM, Jon Kirwan wrote:
> Hi, Al. I've been busy and not following the group. But SD
> cards are interesting to me and I just noticed all the notes.
>
> I looked at the 40-page spec cited by Matthias Weingart
> (v2.2) and saw that it references an SDA Physical Layer
> Specification. I assumed you have to pay for that and I've
> seen that it is at least in V3.0 by now. I haven't been able
> to find that one. But I did find v1.01 and v1.10. Weird
> thing is, v1.01 is almost 900 pages long, while v1.10 that I
> got (and haven't read yet) is slightly over 130 pages.
> Another weird thing is that Matthias' v2.2 is shorter than
> another v1.9 I found, which is about 3 times longer.
>
> The SD Card association has some freely available "simplfied
> versions" which I also grabbed.
>
> Anyway, here are some links:
>
>
>
>
>
>
>
>
>
> The MONSTER one, almost 900 pages, is the first link above.
>
> And since I was rummaging around, I figured I'd also dump out
> this link:
>
> That is a PDF that can be printed out "actual size" on a
> printer being fed with construction paper and then cut out
> and glued with Elmer's to make a spectrophotometer box that
> uses either a DVD-RW or a CD-ROM disk. (Use blanks, if you
> can.) The DVD-R and DVD+R have a huge absorption band in the
> visible red, so don't use those. The DVD-RW is great.
>
> Jon
>

Hi, Al. I've been busy and not following the group. But SD
cards are interesting to me and I just noticed all the notes.

I looked at the 40-page spec cited by Matthias Weingart
(v2.2) and saw that it references an SDA Physical Layer
Specification. I assumed you have to pay for that and I've
seen that it is at least in V3.0 by now. I haven't been able
to find that one. But I did find v1.01 and v1.10. Weird
thing is, v1.01 is almost 900 pages long, while v1.10 that I
got (and haven't read yet) is slightly over 130 pages.
Another weird thing is that Matthias' v2.2 is shorter than
another v1.9 I found, which is about 3 times longer.

The SD Card association has some freely available "simplfied
versions" which I also grabbed.

Anyway, here are some links:

The MONSTER one, almost 900 pages, is the first link above.

And since I was rummaging around, I figured I'd also dump out
this link:

That is a PDF that can be printed out "actual size" on a
printer being fed with construction paper and then cut out
and glued with Elmer's to make a spectrophotometer box that
uses either a DVD-RW or a CD-ROM disk. (Use blanks, if you
can.) The DVD-R and DVD+R have a huge absorption band in the
visible red, so don't use those. The DVD-RW is great.

Jon

Great point. Thanks!

Probably important w/ any web based mail application w/ autowrap "features".

--- On Sat, 2/11/12, Dan Bloomquist wrote:

> From: Dan Bloomquist
> Subject: Re: [msp430] Re: SD CARDS
> To: m...
> Date: Saturday, February 11, 2012, 2:33 PM
>
> Hi guys,
> When posting long urls to a list brackets keep them from
> getting busted:
>
>
>
> I make it a habit even if it is really short.
>
> Best, Dan.
>
>
>
>
>
>
>
>

Got it. Thanks. A space got added right at the line wrap in Mathias' post, so I didn't spot it until your post moved things.

--- On Sat, 2/11/12, carlos 351 wrote:

> From: carlos 351
> Subject: Re: [msp430] Re: SD CARDS
> To: "m..."
> Date: Saturday, February 11, 2012, 1:52 PM
> It seems to truncate the web link,
> just copy the whole line from below, past it into a text
> file, remove the new line that truncates it, then past it
> into your web browser.
>
> regards
>
> From: carlos 351
> To: "m..."
>
>
> Sent: Saturday, February 11, 2012 1:50 PM
> Subject: Re: [msp430] Re: SD CARDS
>
>
>
> http:// http://www.altec-computersysteme.com/downloads/Produkte/Flash_Speicherkarten
> /SD_Cards_miniSD_microSD/SanDisk_SD_Card_Family_PM_v2.2.pdf
>
> From: carlos 351
> To: "m..."
>
>
> Sent: Saturday, February 11, 2012 1:49 PM
> Subject: Re: [msp430] Re: SD CARDS
>
>
> try this onelink
>
> regards
>
> From: Reginald Beardsley
> To: m...
>
> Sent: Saturday, February 11, 2012 1:11 PM
> Subject: Re: [msp430] Re: SD CARDS
>
>
> This is what I get from the link:
>
> Forbidden
>
> You don't have permission to access
> /downloads/Produkte/Flash_Speicherkarten/ on this server.
>
> Additionally, a 404 Not Found error was encountered while
> trying to use an ErrorDocument to handle the request.
>
> --- On Sat, 2/11/12, carlos
> wrote:
>
> > From: carlos
> > Subject: [msp430] Re: SD CARDS
> > To: m...
> > Date: Saturday, February 11, 2012, 11:35 AM
> > They both work, just copy the whole
> > link on a text file remove the new line then past it
> into
> > the web browser.
> >
> > very good bed time reading stuff thanks for sharing
> >
> > Cheers.
> > Carlos
> >
> > --- In m...,
> > Reginald Beardsley wrote:
> > >
> > > 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.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >