STM32F0 SPI CRCERR bit problem (with DMA)

gahelton1 · ‎2015-01-29

Posted on January 30, 2015 at 04:06

I seem to have a problem with the CRCERR bit in the SPI SR for a STM32F031. The CRC generator is turned on, and the RXCRCR gives the correct CRC for the message received. A string of bytes is sent (hex 81 02 00 00 00 00 01) with the 01 being the CRC value for the previous six bytes. The CRCPOLY is 0x107. When all of the bytes are sent, including the CRC, the RXCRCR is 0x0000 - which is correct since a CRC of the CRC value results in 0. In this case, the CRCERR flag is clear as expected. However, to test a bad case, the 01 was replaced with 0x45. This should have resulted in the CRCERR flag being set, but it was not.

A file is attached which has some screen snapshot data of the registers after the data packet was received. Any help would be appreciated.

Thanks in advance.

waclawek.jan · ‎2015-02-02

Posted on February 02, 2015 at 09:13

RM0091, CRC transfer managed by DMA:

''The counter for the SPI transmission DMA channel has to be

set to the number of data frames to transmit *excluding* the CRC frame.''

JW

gahelton1 · ‎2015-02-02

Posted on February 03, 2015 at 02:22

Thank you for the reply.

I have changed the DMA receive count to the number of bytes received, and to the number of bytes received + 1 (for the CRC byte), and the results are the same. No change in the CRCERR flag.

According to the datasheet, in full-duplex mode, it says that the DMA receive count ''can'' be set to the number of data bytes + the size of the CRC. Whatever ''can'' means. A snapshot of that section of datasheet is attached.

________________

Attachments :

Untitled.jpg : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0eZ&d=%2Fa%2F0X0000000bfK%2FJNOIHWW3Ax9AkFPFOWnLJShHmnS3TrepmUgF0o1LshM&asPdf=false

henk2 · ‎2015-02-08

Posted on February 08, 2015 at 10:39

Hi,

I also encountered a lot of trouble getting the CRC check to work. Using DMA I changed the polarity of SCK and MOSI and then it worked. In my case, I think, the ULINK-ME debugger I use, uses some same pins as one of the SPI peripherals. Not sure. Because of unpredictable SPI data corruption (Yes CRC working!)(probably due to a combination of using external memory). Last week I dropped using the DMA but encounter new CRC problems. On SPI the last received data equals the calculated CRC on the other SPI it does not. Artificial adding one extra bit in the data stream is not recognized by the CRCERR, both SPI's always return PASS...Still investigating at this moment. Let you know when solved.

Henk

gahelton1 · ‎2015-02-08

Posted on February 08, 2015 at 19:39

Hi Kenk,

For now, I've given up on the CRCERR flag for a CRC error indication. Instead, I send the CRC byte and let the CRC hardware generate a CRC value of 0x0000 when the CRC is good. Something else otherwise.

I will contact ST support and let everyone know the answer. Apparently there aren't very many people using this feature.

Thanks.