I am attempting to interface an XMEGA 256A3U to a µSD card using SPI.
I have the hardware working, and all seems to go well until CM17 to read a single block.
I am using Chan's fatFS, release 0.13c - which I think is the latest.
I'm using a SanDisk 2GB micro-sd card.
So here's the story so far...
Figure 1. Over of timing from my logic anlayser. From the top, signals are: CS, MOSI, MISO, SCLK
And zooming in on the important parts...
Figure 2. First command sent - CMD0 - Enter Idle Mode. This puts the device into SPI mode.
The correct response "0x01" is received meaning "Everything's fine, and I'm in Idle mode"
Fig 3. Then, CMD8 is sent, and the sync pattern is correctly returned:
Fig 4 & 5 ACMD41 is sent. This reports the hosts capacity support to the card, and activates initialisation process.
Since ACMDxx are "App Commands" they are always prefixed with CMD55 So here is CMD55 followed by ACMD41:
Note the 0x01 response which means "still initialising..."
And the ACMD41 is repeated until we get an 0x00 (ready) response as seen here:
So now we can issue CMD58 to read the OCR register:
So all is well and good up to this point, so now I issue CM17 - READ_SINGLE_BLOCK.
This command responds with 0xFF until it's ready to send data, then 0xFE to tell you the data follows, and then the DATA:
But as you can see, the data is all 0x00 - the first two bytes for a formatted card should really be:0x55AA
This car still works fine an a PC and is formatted for Fat32.
So why does the CM17 (Read single Block) return all zeros?
Anyone see where I have gone wrong?