SD card interfacing

[evandude]

I have been playing around with interfacing an SD card using SPI mode on an 18F2550. I've succeeded in getting through the initialization sequence, but now I think I'm stuck. FYI, I'm bit-banging the SPI interface, and have a logic analyzer hooked up to the 4 SPI lines to verify everything that's going on. I haven't included code here because I'm verifying that what I'm "trying" to do is what's actually happening on the data lines, rather than just trusting the code blindly.

Once the initialization is complete, I'm trying to do a single block read, so I send CMD17 (with address 0x0000, crc 0xFF because I don't have CRC enabled) and wait for the R1 response, which is 0x00 as it should be, and then wait for one of the two possible responses: a start token, or an error token.

The problem is that the start token should be 0xFE, and the error token format has the 3 MSB's as zero. The actual response I get is 0xFC, which fits neither of those descriptions - and then the card holds the data line low, at which point I have to send it hundreds of clock cycles to get it to release it, or reset it.

When I try the SEND_CSD command instead, it does the same thing except it utterly refuses to release the data line unless the PIC is reset.

I can't seem to figure out what's going on... Anyone got any advice? Is there anything I'm forgetting to do, ie - do I need to do anything other than initialize the card and then try to read from it?

 

[Nigel Goodwin]

If you google there's a number of sites dealing with SD cards and PIC's, here's one example http://www.captain.at/electronics/pic-mmc/

 

[eblc1388]

These information is what I have gathered from the gurus. You might already have done the following, hope it helps:

1. When you send CMD0 command to place the SD card into SPI mode, you have to make sure it is placed in that mode by checking for the 0x01 response.

As end of each command, dis-select SD Card and send one more 0xFF (sends 8 more clock pulses). These can actually be done in either order.

2. Then you check for completion of initialization of SD card using the CMD1 command, for a 0x01(still busy) response or a 0x00(done) response. Wait until you get a 0x00 response. This might take up to a second for very large size SD card.

3. Send other commands.

 

[evandude]

@Nigel:
Thanks for the link, unfortunately their code just reinforces what I've been doing. They go through the same type of initialization, and then to read they send the READ_SINGLE_BLOCK command, and then do:
while(SPI(0xFF) != 0xFE);
which in my case results in an infinite loop since I get a 0xFC and then a ton of 0x00's and then it eventually goes back to 0xFF.

@eblc1388:
Yeah, my initialization routine is just that - CMD0 followed by repeating CMD1 until I get a 0x00 response. According to the spec, the state of the chip select line is unimportant when sending the extra 0xFF, and from what I've seen in example code, everyone just pulls CS low (after having it high for a bit prior to initialization) and leaves it there. I've tried it both ways.

In any case, the initialization sequence works fine... it usually takes 3-5 cycles of sending CMD1 to get the 0x00 response.

But as soon as I send a READ_SINGLE_BLOCK command, it responds with an R1 response packet as it should, then 0xFC, pulls the MISO line low and just sits there locked up.

I'm at my wit's end. I guess I'm going to take a closer look at all the signals with an analog probe, instead of just using the logic analyzer, to see if they're just noisy or something, which would be an easy fix... If that's not the case I'm not sure what to do because I still can't see any way in which I'm really deviating from the specification and/or from example code I've come across...

 

[eblc1388]

Judging from the card response received, your interface is working. Why the card has problem with the CMD17 is but anyone's guess. Can you confirm you did de-select the card between each command? This seems to be the practice most software programmers used.

Focus first on doing a successful CMD9 to read the CSD registers before reading blocks.

Do you have another SD card to try out?

 

[evandude]

Okay, well I think I may have solved it. On closer inspection, I noticed that not only was I getting that weird 0xFC response, some other card responses looked like they weren't aligning to the 8-clock-cycle bursts, like the card had missed some clock cycles somewhere, and it didn't seem to be consistent.

I tried changing the voltage divider resistors I was using on the PIC outputs (to go from 5v to 3.3v) to lower values to get better transition edges, but it didn't fix the problem.

I then ripped out the voltage regulator I was using and powered the card directly from my bench power supply set at 3.3v, and now everything seems to be working. The initialization routine is only having to repeat CMD01 like 2 or 3 times, as opposed to 5 or more times previously, and the READ_SINGLE_BLOCK command is giving me a proper R1 response (0x00) every time, followed by a 0xFE like it should - and the card remains responsive afterward, rather than seeming to "lock up".

Gotta love power supply issues for being a pain to track down...

 

[eblc1388]

Congratulation. Complex problem always has simple answer.

I would think power supply issues like ripples, noises or oscillations are the first thing one would check if the circuit is behaving intermittently. Too many incidents reported here turn out to be power supply related. Many happened with using the simple 7805!