SD card interfacing

[lpcware]

Content originally posted in LPCWare by IanB on Wed Apr 09 10:02:53 MST 2014
I'm just starting to write the code to interface an SD card to the SPI port (of a LPC1114).

1) To match the SD card spec, it would appear that CPOL=0 and CPHA=0 to give the right clock edges and phases. I don't quite follow why SSEL has to be pulsed HIGH between each data frame. Could someone please explain.

2) After sending an SD Command, the SD card requires 8 dummy bits (with Din (that's MOSI) HIGH), and then for the Dout  line  (MISO) to be read ONE BIT AT A TIME until a zero appears indicating the start of the Response message.

Is there a way of reading MISO one bit at a time, other than taking control of the pins back from the SPI port and toggling SCKn manually?

I have looked at the code in various SD card drivers, and they read a whole byte from MISO. If this works how does it make sure that it aligns with the zero start bit?
It doesn't appear that the SD card spec guarantees any specific number of dummy clocks between the end of the command and the start of the response.

[lpcware]

Content originally posted in LPCWare by IanB on Sat Apr 12 14:39:21 MST 2014
Thanks. It confirms what I thought . . . and it means that there is a lot of bad software out there! Most SD card projects simply read 1 byte from the card to get the response. No wonder people have trouble with it.

The SD card spec almost seems as though someone had looked at the interface for a SPI EEPROM and said "let's see how complicated we can make this"

I've looked at the linux driver you suggested: it waits for a byte that is not 0xFF, (meaning that the response is in there somewhere) then reads the next byte, (to make sure it has all the response) then shifts it until the bit 15 is zero, which puts the response byte in bits 8-15.

The only snag is that when the data token comes back misaligned, it means that every single byte in the data stream has to be shifted back into alignment . . . which is OK if you have all the time in the world.

I've a week or so to ponder upon this until my prototype pcbs arrive, but I think I'm going to try switching the SPI pins back to GPIO, toggling SCK manually until a zero appears on MISO, then switching back to SPI, and reading a 7-bit word.

Then I have it back in alignment, and I can read the data in as 16-bit words.

It will be sort-of "one-time-use" software, as porting it to any other processor will mean getting all the right GPIO bits.

[lpcware]

Content originally posted in LPCWare by wmues on Wed Apr 09 13:23:45 MST 2014
Oh, the 8bit SPI problem....

In theory, the SD card spec in SPI mode requires only multiple of 8 bits. But in practice, some SD cards send the ZERO bit in the middle of a byte. This happens both for responses and for data blocks.

Your driver should be able to deal with this problem. The best solution is to shift the incomming bytes.

Take a look at the linux mmc_spi driver: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/mmc/host/mmc_spi.c...