SPI SD Card with CRC

[dsjnews]

Posted on June 08, 2013 at 11:56

Hi,

I am looking to understand exactly what CRC support the STM32F103 provides when interfacing with an SD card using an SPI channel and no DMA. I am using an Olimex STM32-P103 development platform and have successfully transmitted CMD8 to a SanDisk 2GB (class 2) SD card (at 280KHz) but only when I pre-calculate the 6-byte command as follows. 40 00 00 00 00 95. The reply data that is returned in this case is valid. I would like to use the built in CRC capability of the interface to calculate the final CRC byte but this is where things go wrong. I now transmit 40 00 00 00 00 and on the final 00 byte set the CRCNEXT bit in the CR1 control register. I do indeed get a sixth byte transmission but it is not the required 95 (this I verified by viewing the MOSI signal using an oscilloscope). My questions are as follows. (*) In order for the calculated CRC value to be useful only the low 7-bits should be used which need to be shifted left 1-bit position and a LSB of 1 needs to be set (to satisfy the SD card protocol for transmitted commands). Does this happen automatically or is the byte transmitted the final CRC calculation which will be invalid in most cases? (*) If the latter does not happen then am I correct in thinking that this must be managed by user code? If so how would this be achieved if DMA transfers are used? (*) Is register SPI_CRCPR actually programmed with a generator polynomial or is it simply set to 7 to select CRC7 (with left-shift and LSB set to 1 prior to transmission)? Regards FarmerJo #crc #crc #spi #spi #sd-card #sd-card

[Tesla DeLorean]

Posted on June 08, 2013 at 12:54

The hardware supposedly supports the CRC for the SD/MMC interface, my reading of the docs suggests you have to use DMA to transmit one less byte, and handle the CRC byte in the TC interrupt of the DMA. ie you read it from the CRC accumulator, perhaps shift it, and then stuff it in DR manually when TXE.

Now, I've implemented SPI support of SD/SDHC cards on a F107, and I'd observe that there are only a couple of commands that need a CRC, and they are all fixed. Without DMA and 4-bit SDIO it did appear to be 30x slower than an F205/7 doing the same thing.

[dsjnews]

Posted on June 08, 2013 at 19:31

Thanks Clive,

So it appears that contrary to the ST documentation the calculated final CRC value is NOT valid for the SD card protocol. This does agree with what I am able to observe. I am thinking out loud now. Perhaps a possible scheme may be to generate an interrupt after the fifth byte has been transmitted and use this to shift the current CRC value left with LSB set and then transmit this byte from the interrupt. I will do something along these lines and let you know if this can be done. I suppose one interrupt per SD card transmission is OK compared to the time it takes to manually calculate a CRC value as the data is transmitted. The reason that I want the correct CRC transmitted is that some people are reporting that for some cards there are problems with invalid CRCs even though CRC checking should be disabled by default. Regards FarmerJo

[Tesla DeLorean]

Posted on June 08, 2013 at 20:05

I'm pretty sure 7 is not the right value for CRC7, which has a different polynomial, and function.

''The hardware CRC generation/verification supports basic SD Card/MMC/SDHC(a) modes.'' Somehow I think this is talking about the CRC16 on the data, not the CRC7 on the command.

[dsjnews]

Posted on June 09, 2013 at 21:27

Yes that would explain a fews things! I will try to get clarity about this point at ST this week some time.

Regards Farmer Jo

[EGoep]

Well you probably already found an answer to your question by now,

But to clarify the situation, as im testing the crc function of the SPI peripheral as well, NO you cant just write 7 into the CRCPR register.

CRC7 just means u will have a 7 bit CRC at the end of the calculation, i.a you need an 8 bit polynomial, which is defined in the SD CARD specification as P(x) = x^7+x^3+ x^0 = 0x89.

However, using this polynomial in the CRCPR register doesnt hasn't been giving the expected answer for me so far, which is problematic for the SD card CRC7 calculation.

If you managed to make it work you' re free to post the right setup for the CRC calculation .

Thanks.

Eric

[Tesla DeLorean]

The thread is from nearly SIX years ago, so don't hold your breath.

Are the bit positions even right? I built a CRC7 in software to do this.

The DATA has a 16-bit CRC.

SPI is slow, filling a multi GB card via SPI will be glacial.