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 -- You received this message because you are subscribed to the Google Groups "jallib" group. To view this discussion on the web visit https://groups.google.com/d/msg/jallib/-/m44Dv6IM3H0J. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
