I am interfacing an SD card through SPI using an AVR microcontroller (more specifically it is the Uzebox console).
I can successfully initialize the card with turning CRC check ON with CMD59 (so I have a proven working CRC7 algorithm), and can read sectors from it (dumping the data read by CMD17 gives correct results: I see what is on the card proper).
What I can't seem to get working is a CRC check for the data sectors using the CRC bytes received from the card.
I currently have three SDSC cards which I verified to behave in the following manner with my algorithm:
-
Two of the cards give the same value for both CRC bytes, neither corresponding the result of CRC-CCITT with either 0x0000 or 0xFFFF start value (tested with multiple sectors, the values change according to the data of the sector, but the two bytes are always the same).
-
The third card seems to have no CRC at all, providing 0x0000 on these bytes.
The SPI transmission code for those final bytes seem correct, I did some steps to verify that I indeed read what I want to including that I really do two SPI transactions for the two bytes.
Anyone have any idea what could be happening there? Or should I just forget about those CRC bytes? (maybe the cards just not implement them or do it incorrectly in SPI mode)
Best Answer
So, regarding the two "CRC-delivering cards": It's kind of hard to debug this without any example data and CRC, but the most common problem one encounters is that the generator polynomials are "meant" the other way around, ie. whether \$x^0\$ corresponds to the first or the last bit.
Checking is easy: just have test data that you have both in original and reversed bit order, and see what makes sense.
Now, you've tested with 0xFFFF and 0x0000 already, which are symmetrical. At least for 0x0000, the result of a polynomial should definitely be zero, shouldn't it? What are you expecting, what are you getting?
Reference:
http://users.ece.utexas.edu/~valvano/EE345M/SD_Physical_Layer_Spec.pdf , p. 54f