SD card over SDIO bus initialization problem because of failed CRC

Question

I have a custom board based on an ST Microelectronics STM32F103VE microcontroller, with a MiniSD card plugged over the microcontroller's SDIO bus. The electrical connections were done exactly as found in the STM3210E-EVAL board schematics, checked and rechecked so I have strong confidence they are correct. Unfortunately I don't have that eval board to test whether what I'm experiencing is a hardware problem, but it doesn't seem so. For the tests below, I'm using a Kingston 2 GB MicroSD card (model MBLYG2/2GB) bought very recently (so it should comply with the newest SD card spec) with the supplied MicroSD to MiniSD adapter; haven't tested with any other cards yet.

I'm following the SD card physical layer simplified spec to understand what's going on. The code that I'm using is the example SDIO code that comes with ST Micro's standard peripheral library for this microcontroller. It starts out by sending CMD0 (GO_IDLE_STATE), then CMD8 (SEND_IF_COND), and then ACMD41 (SD_SEND_OP_COND), which is done by sending a CMD55 (APP_CMD) followed by CMD41. The clock line is clocked at 400 kHz, and as part of my debugging efforts, I've added a delay of about 100 clock cycles between CMD0 and CMD8, as I've read somewhere that it was required, at least when operating in SPI mode. Other than the modifications mentioned below, the code is exactly the same as the example code.

When I first tried to run the example code, CMD55 had a problem which happened to be because the microcontroller was buffering the response to CMD8, but the sample code didn't retrieve CMD8's response, so when checking the response to CMD55, the code was actually looking at the response to CMD8 and was upset by that. I fixed this problem by clearing the CMDREND flag on the microcontroller's SDIO peripheral before sending out CMD55, so when the code checked the response to CMD55, it no longer had CMD8's response buffered.

The next problem, and the one I'm currently stuck at, is that in the response to CMD55, bit 23 of the card status field (COM_CRC_ERROR) is set, which indicates the CRC check of the previous command failed according to the spec. Although the microcontroller automatically calculates the CRC, I hooked up a logic analyzer to the circuit to verify it was correct. I'm using a web app (sorry, can't link because I'm a new user, but just Google for "CRC ghsi" and it's the first result) to verify the CRCs, using the polynomial x^7 + x^3 + 1 as per the spec. This is the logic analyzer output, formatted and commented by me:

// uC sends CMD0, CRC OK, no response:
01 000000 00000000000000000000000000000000 1001010 1
// uC sends CMD8, CRC OK, check byte = 0xAA:
01 001000 00000000000000000000000110101010 1000011 1
// SD card responds to CMD8, CRC OK, check byte echoed back = 0xAA:
00 001000 00000000000000000000000110101010 0001001 1
// uC sends CMD55, CRC OK:
01 110111 00000000000000000000000000000000 0110010 1
// SD card responds to CMD55, CRC OK, note card status bits 23, 8 and 5 set;
// bit 23 = COM_CRC_ERROR, bit 8 = READY_FOR_DATA and bit 5 = APP_CMD:
00 110111 00000000100000000000000100100000 0000100 1

Also note that if I attempt CMD55 a second time immediately after the exchange above, bit 23 is unset:

// uC sends CMD55, CRC OK:
01 110111 00000000000000000000000000000000 0110010 1
// SD card responds to CMD55, CRC OK, bits 8 and 5 still set but 23 not set:
00 110111 00000000000000000000000100100000 1000001 1

Note that I tried sending CMD8 twice before sending CMD55, but it made no difference, the first CMD55 always returns bit 23 set. I can reproduce this every time I try, so I don't believe it's an issue with glitches or noise. Considering the CRCs are calculated by the microcontroller itself, they look correct as seen by an external entity (the logic analyzer), and have been verified on the website I mentioned above, I don't see how the card's CRC check could be failing.

Is this somehow expected? Maybe I should wait a set number of clock cycles between each command (somewhere I read it should be 8 cycles, and I believe I'm respecting that)? Can I just send a second CMD55 if the first fails and be on my way, or will there be any negative consequences? Even if that fixes the problem, I'd very much like to know why the CRC check is failing, as I don't think I'm doing anything wrong.

Answer 1

I found the problem. After I had to modify the code to flush the buffer for the CMD8 response, so that CMD55 read the correct response, every test I made had the logic analyzer hooked up to the circuit. After removing the logic analyzer, the code started working -- probably it was injecting noise into the lines. No delays were required, but just to follow the spec, I added a 74+ clock cycles delay before CMD0.