sd-cardspi

microSDHC card returning junk bytes during data transfer portion of CMD25 WRITE_MULTIPLE_BLOCK, why/what are they?


I'm writing a low-level driver in C to communicate with a microSDHC card over SPI. So far I have been able to successfully initialize the card, read a single block, read multiple blocks, and write a single block (block size 512). But, when I try to write multiple blocks, the card responds to CMD25 (write multiple blocks) correctly, but then as the first data block is sent, the card seems to echo the start data token (0xFE) and then send junk (?) bytes periodically.

I expect to see 0xFF from the card during the data transfer, so I'm not sure why I'm seeing those bytes, or what they mean. Can anyone provide insight on what might be wrong or how to determine why the card is responding with those bytes?

More info:

Here's a trace of CMD25 and start of the data transfer on my setup:

enter image description here

So, I transmit the command bytes [0x40 | 25, 0x00, 0x00, 0x00, 0x00, 0x01], which is the format to perform a multiple block write starting at address/sector 0. The card responds with 0x00, indicating it is in READY state. Then, I send the data start token (0xFE) followed by 514 bytes of 0xA5 (512 block + 16 bit CRC that is not checked by the card). But, for some reason the card is responding with 0xFE right after I send it and as the trace shows I periodically get non-0xFF bytes from the card during the data transfer. The value of the junk bytes changes each time I run it, but seems to always be preceded by 0xFE from the card.

The microSDHC card is Kingston brand, 32gb, and as far as I can tell from the datasheet, it should support CMD25.

Here's a trace of CMD24, single block write, and the start of the data transfer, which does work correctly, and I verified by reading the block back:

enter image description here


Solution

  • I figured out the problem. The "start" block token for multiple block writes with CMD25 is 0xFC, different from the start token for single block writes with CMD24, 0xFE. After using 0xFC, the SD card is responding correctly to CMD25.