SD Card Initialisation

[PDSACAA]

Hi all
I have been studying the SAN DISK documentation referred to by Matt in his SD card tutorial and I am prompted by the recent posts on SD card use to make observations/ ask for clarification on what is undoubtedly a complex issue.

However can I first of all thank Matt for his interpretation of this document into the SD card library which must have been no mean task. I have used his library successfully with a SAN Disk 2Gb card on a number of occasions without problems so I hesitate to even query his code.

Most reported problems arising from the use of SD cards seem to be centered on the INIT procedure so comments on the following would be good. Sorry if the following is long winded but the documentation is lengthy.
 
SD card INIT considerations

I see these as the potential card states at execution of an INIT procedure
1) Card powered down.
2) Card powering up/initializing.
3) Card in SD bus mode - idle state. (default powered up state)
4) Card in SD bus mode - ready state.
5) Card in SD bus mode - busy state.
6) Card in SPI bus mode - idle state.
7) Card in SPI bus mode - ready state.
8) Card in SPI bus mode - busy state.

(the numbering is just for brevity nothing to do with documentation)

In practical terms of these states presumably INIT only needs to cater for  2 and 3 for the following reasons.
1) Can't do much about this unless PIC has control over SD card supply voltage - assume card is powered up.
4) and 5) Should not be a problem in our project if our PIC is the only controller accessing the SD card with the
chip select line tied to the controller in SPI bus configuration.
6) Catering for 2 and 3 will force this out of idle state (however this seems a bit top heavy) and anyway along with
7) and 8) why would we be doing an INIT on a card already firmly in SPI mode.

So looking at Matts INIT procedure can I ask about the following.

Prior to the main loop we see  a CS low, wait 1 msec. ,CS high.
Can I ask why? What requirement does this address ?

Then presumably the 10 FF's sent (note with the CS still high!) are to cover the reference to 75 logical 1's sent on CMD line as part of the card power up/ initializing sequence?
However documentation says send logical 1's for larger of 1msec, 75 clock ticks, or supply ramp up voltage time.
By my reckoning even with FOSC at 4Mhz and  SPI _RATE_FOSC_64, 80 clocks ticks is only just over 1 msec.  Any other combinatons of FOSC and SPI_RATE_FOSC will be well under 1 msec.
Shouldn't we be doing 1 msec worth of logical 1's based on oscillator and SPI clock speeds? As for supply voltage ramp up time if it was known it could be an optional CONST or parm for INIT and compared with 1msec/75 ticks? Am I over complicating this?

This initializing sequence is pertinent for state 2, Card powering up/initializing.
I have no idea from documentation what effect this has on a card already in state 3,
Card in SD bus mode - idle state. Hopefully nothing!! Does anyone have any other ideas.

Anyway at this point we would hope to have a card firmly in state 3 and lets face it this is the most likely state in which we would find an SD card in our circuit at the time of executing INIT. i.e powered, initialized, SD bus mode (default) and idle state.
Now we would like to get to state 7, Card in SPI bus mode - ready state.

So

In the main loop can I confirm the following:-
With CS low, we are issuing a CMD0 (card reset) to force the card into SPI mode (idle state) and noting the response.
Can I ask here about the response? Do we know that as a result of any single CMD0 the card will have noted the request, switched to SPI mode, delivered a meaningful response (in SPI mode) and then gone idle.  If so we would expect the response to always show “idle state”. Can the response to a CMD0 show anything but “idle state”?
For example might it show “not (yet) in idle state”, but with the understanding that it will get there as soon as possible.
Due to timing or other peculiarities can the card miss this CMD0 requiring further attempts to switch to SPI mode.
This seems to be the case in the case of Matts code where he allows up to 100 retries
of CMD0 while (I think) watching for an acknowledgement that the state goes to idle but then to ready (non idle) by using the CMD1 (initialize card) response to monitor this.

Again with CMD1, presumably the card response to the command could be “in idle state (still)” but with the understanding that it will get to a ready (non idle) state as soon as possible after initializing.

Is the above analysis anywhere near correct?
I would really value any comments, clarity or objections by members to the content.
It is difficult to work in isolation on some of these problems.

Kind Regards
Dave Paxton 

[mattschinkel]

Hi Dave, I'll try to answer the best I can as I haven't worked on the init proc in a while. First thing you should know is that we may not be working with a card/circuit that is powered down. The card could be in read or write state. I had trouble with a stuck card if I restarted the PIC without power off. The extra code is for this purpose.

 

You said you read SAN DISK documentation, but you should also give SD Card specification 2.0 a read. I think there is a 3.0 specification as well.

 

 
>> Prior to the main loop we see  a CS low, wait 1 msec. ,CS high.

>> Can I ask why? What requirement does this address ?

 

   -- steps to set sd card to use SPI
   sd_chip_select = low      -- start chip slect low
   _usec_delay(1_000)        -- delay
   sd_chip_select = high     -- chip select high

This is so the sd card starts in SPI mode to use the SPI bus instead of sd card bus.

>> Then presumably the 10 FF's sent (note with the CS still high!) are to cover the reference to 75 logical 1's sent on

>> CMD line as part of the card power up/ initializing sequence?

   for 10 loop
      spi_master = 0xFF    -- send clock pulses (0xFF 10 times)
   end loop

Yes, according to documentation, we are required to send some clock pulses. The sd card may be doing something internally at this point such as clearing a shift register.

 

>> However documentation says send logical 1's for larger of 1msec, 75 clock ticks, or supply ramp up voltage time.

>> By my reckoning even with FOSC at 4Mhz and  SPI _RATE_FOSC_64, 80 clocks ticks is only just over 1 msec. 

>> Any other combinatons of FOSC and SPI_RATE_FOSC will be well under 1 msec.

>> Shouldn't we be doing 1 msec worth of logical 1's based on oscillator and SPI clock speeds? As for supply

>> voltage ramp up time if it was known it could be an optional CONST or parm for INIT and compared with 1msec/75

>> ticks? Am I over complicating this?

 

I'm not sure where you have seen this documentation about the 1ms of logic 1's, but I have no objection to changing this. Maybe SAN DISK has different specs. You may show me some new code and what you wish to change it to. There is an oscillator speed constant provided by the compiler or the device files, I can't remember what it is.

>> Can I ask here about the response? Do we know that as a result of any single CMD0 the card will have noted the

>> request, switched to SPI mode, delivered a meaningful response (in SPI mode) and then gone idle.  If so we

>> would expect the response to always show “idle state”. Can the response to a CMD0 show anything but “idle

>> state”?

 

You'll have to check sd card spec for responses, I can't remember. From my code, I can see response of 0 means it is not idle.

>> Again with CMD1, presumably the card response to the command could be “in idle state (still)” but with the

>> understanding that it will get to a ready (non idle) state as soon as possible after initializing.

The look will exit as soon as wee get one good response from SD_GO_IDLE_STATE.

 

Part of the reason for this loop is to get the card is out of a read or write status.

 

I actually have some code somewhere to init a high capacity card. I was able to get a response from one of these, but was never able to read or write to SDHC cards.

[PDSACAA]

Matt
Thanks for prompt reply your input is much appreciated, however as I anticipated
as a result of your response  I wonder if I understand this subject at all!!
As you say I will give SD Card specification 2.0 a read.

Before I respond can I say that information I quote is from
the document you identify in your tutorial viz:-

San Disk Secure Digital Card
Product manual
Version 1.9
DocumentNo. 80-13-00169
December 2003 (This is the most up to date version of this particular document that I could find but obviously products move forward)

Regarding the CS High, 1msec wait, CS low thing to force SPI mode
I am very confused. Referring to the product manual section 5.5.1 SPI Mode Selection says

"The SD Card wakes up in the SD Bus 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 Bus mode is required it will not respond
to the command and remain in the SD Bus mode. If SPI mode is required, the card will switch to SPI mode and
respond with the SPI mode R1 response."

This what I thought your outer loop was doing by executing CMD0 after asserting CS. I did not really understand why you allowed
for 100 repetions of this loop except that I could understand you wanting to see at least one confirmation of "GO-IDLE" state
before pulling it up with a CMD1 (card initialisation ) and checking for "ready" state. Have I interpreted this wrongly?


Information about sequence of logical 1's is contained in product manual section 3.4.1 Power-Up

"After power up, the host starts the clock and sends the initializing sequence on the CMD line. This sequence is a
contiguous stream of logical ‘1’s. The sequence length is the maximum of 1msec, 74 clocks or the supply-ramp-uptime;
the additional 10 clocks (over the 64 clocks after what the card should be ready for communication) is
provided to eliminate power-up synchronization problems."

Also, if we catch the card powering up and hence, as you quite rightly say, need to execute this power-up/initialization sequence,
surely this must be done prior to trying to move the card into SPI mode?

Although not wishing to extend the discussion too widely can I ask about another procedure in the library that I have examined since my post.
Again I am worried that I am not seeing things clearly when I look at procedure sd_set_idle. Here you issue a CMD0 to request the card to move
to an idle state.Exactly so, but then you poll using CMD1's till you get a clear response. The thing is I understood that a CMD1 will cause an
initialization of the card and (given time) bring it back to a ready state and hence a clear response.
(response "idle_state bit" bit 0 = 0 assuming all other 7 error bits are clear also).
If we are asking the card to remain in idle state shouldn't we be checking the Card status using CMD 13 and checking R2 response (byte 1,bit 0)  for  a positive In_idle_state rather than using CMD1?

My head is spinning please have patience!!

Kind Regards
Dave Paxton

[mattschinkel]

I could of course interpreted the documentation wrongly as well. I think the question for me is, what is wrong with the current setup? I think setting my SD_DELAY_AFTER_WRITE constant to false fixes any issues people have had.

>> Regarding the CS High, 1msec wait, CS low thing to force SPI mode

>>

>> This what I thought your outer loop was doing by executing CMD0 after asserting CS. I did not really understand why you allowed

>> for 100 repetions of this loop except that I could understand you wanting to see at least one confirmation of "GO-IDLE" state

>> before pulling it up with a CMD1 (card initialisation ) and checking for "ready" state. Have I interpreted this wrongly?

 

So the loop has 3 features:

1. It will put the card into SPI mode as you suggest

2. It will fix a card that is already powered on and in the middle of a read or write. Such as if the PIC was restarted but not the entire circuit. The PIC may have been restarted in the middle of a read or write, waiting for more clocks.

3. If a proper response is not received, it will retry. However, if we get the correct response the first time, the loop will stop.

>> "After power up, the host starts the clock and sends the initializing sequence on the CMD line. This sequence is a
contiguous stream of logical ‘1’s. The sequence length is the maximum of 1msec, 74 clocks or the supply-ramp-uptime;
the additional 10 clocks (over the 64 clocks after what the card should be ready for communication) is
provided to eliminate power-up synchronization problems."

>> Also, if we catch the card powering up and hence, as you quite rightly say, need to execute this power-up/initialization sequence,
>> surely this must be done prior to trying to move the card into SPI mode?

 

By reading that documentation, it looks like I am doing it correctly except that I do not check for a "maximum of 1msec" which will only occur for a PIC running at 4mhz or less. This is what you said before but maybe you read it wrong.

 

You had said "However documentation says send logical 1's for larger of 1msec, 75 clock ticks, or supply ramp up voltage time.". The part where you said "send logical 1's for larger of 1msec" is incorrect.

 

>> I look at procedure sd_set_idle.

I'll have to look into this one a bit more, I don't think the only reason for CMD1 is for init. What will be the bennifit of using CMD 13?

[PDSACAA]

 Matt
Thanks for your feedback.
Regarding the points you make you start by asking "I think the question is for me, what is wrong with the current setup"
From my experience absolutely nothing wrong! As I said at the beginning of this post I have used your code with success and do not wish to find fault. I only to wish to clarify things I do not understand about workings of the SD card specification.

Actually I was very surprised and pleased when I bought an SD card reader, wired it up according to your tutorial notes, used your SD card example and library and the thing worked first time. This gave me the encouragement to try to understand how SD card works and how your code achieves this. So thanks again for your effort.

One point you make in your last post is:-
 "2) It will fix a card that that is powered up and in the middle of a read or write......."
You are of course correct.
This would fall under state 8) of the conditions I mentioned in my post namely

8) Card in SPI bus mode - busy state.

I had missed the possible need to get a card out of busy mode under certain conditions that you mention, concentrating only on the card under power up or idle states.
I understand and accept your comment.

In a later comment you say "I don't think the only reason for CMD1 is init". This is an interesting point because
I too do not really understand what the full implications of the results of each command (assuming they are accepted and executed by the card) really are.
The SAN DISK documentation command table only vaguely refers to CMD1 "initializes the card" but what exactly does this mean?
Elsewhere the documentation seems to imply that the end result of a CMD1 command execution is to place the card in "ready to receive further commands" mode.

This is why I queried the use of CMD1 in your sd_set_idle procedure after issuing a CMD0 to request the idle state. Since to obtain and query a card response using CMD1, in order to check that the card had entered idle state would in fact bring it OUT of the idle state (if it had got there) and make it ready. As I understand it using CMD13 would let us check the card status register to establish that the card had in fact entered idle state but without causing a state change itself.
The card state should not change as a result of issuing a CMD13.  Hope this makes sense.



Kind Regards
Dave Paxton

[mattschinkel]

>> As I understand it using CMD13 would let us check the card status register to establish that the card had in fact

>> entered idle state but without causing a state change itself.
>> The card state should not change as a result of issuing a CMD13.  Hope this makes sense.

 

This sounds good, and I may have only used CMD1 because it is a simple command that I knew, and just wanted to check that the card would give a correct response.

 

So... try out CMD 13, see if it works and improves the library. Maybe it's faster as you say. If your tests go well, I can add your code to the lib.

 

I assume you cannot use CMD13 while you are in the middle of a read or write, and therefore will need to change the state before using this command.

 

stopwatch lib is great for testing speed, maybe compair the speed of CMD13 vs CMD1 with response checks.

 

It is great to have someone interested in library improvements :)

 

Matt.

[Rob Hamerling]

Hi Matt,

On 3-11-12 02:08, mattschinkel wrote:

> It is great to have someone interested in library improvements :)
> Matt.

I agree!!!! And I wish that more people would really participate, even
the tiniest contribution is appreciated!

Regards, Rob

--
R. Hamerling, Netherlands --- http://www.robh.nl

[PDSACAA]

Matt/Rob
Thanks for feedback and encouragement.
I will swat up some more on the SD card command implications as discussed and obviously run some test code.
I must as you suggested earlier Matt give SD Card specification 2.0 a thorough read.

If I can later contribute any helpfull code I will certainly submit it for scrutiny.

Kind Regards
Dave Paxton

[mattschinkel]

Hi Mike... Any contribution is worthwhile, big or small :)

On Monday, November 5, 2012 2:09:36 PM UTC-5, Mike K wrote:

Okay, What would be a worthwhile contribution?

Mike