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 On Wednesday, 31 October 2012 08:40:01 UTC, mattschinkel wrote: > > 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? > -- 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/-/iHIIcYgEa24J. 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.
