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 -- 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/-/kOQ9pLjz_mkJ. 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.
