cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F7xx: SPI CRC Checking Error even when CRC matches

andywild2
Associate III

Dear Sirs, we have a SPI CRC problem we thried heavily to solve, but no success.
We broke it down to just send one byte of data, so the CRC is known in advance and it is easy to debug.
Here the description what we did:

Devices

  • Master: STM32F7 (SPI1)

  • Slave: STM32F4

  • Communication mode: SPI full duplex

  • Data width: 8 bit

  • CRC enabled on both sides

CRC Configuration

  • CRC polynomial: 0x07

  • Data size: 8 bit

  • MSB first

  • Only one data byte used for testing

Test frame
Data byte transmitted by slave:
0x55

Expected CRC (CRC-8, polynomial 0x07):
0xAC

SPI clock
The SPI clock on the master is set to the lowest possible speed:

Prescaler = 256

Therefore there should be no timing issue with the CRCNEXT bit being set during the last data frame is clocked.
We use HAL 1.3.3 and HAL_SPI_TransmitReceive_IT on the master side


Observed SPI signals (oscilloscope)

On the SPI bus we observe exactly the expected sequence:

0x55
0xAC

So the slave transmits the correct CRC value.


Master behaviour

When the first SPI interrupt occurs on the master (STM32F7):

  1. A byte is written to the SPI DR register to generate clock.

  2. Immediately afterwards SPI_CR1_CRCNEXT is set.

This causes the CRC phase to start automatically and the slave sends its CRC.

No further write to DR is necessary in this context, because data length is one byte only


Registers on the master after the CRC was clocked in and communication finshed:

CR1
0x0000217C

CR2
0x0000176C

SR
0x00000403

DR
0x0000AC55

RXCRCR
0x000000AC


Interpretation

  • DR = 0xAC55
    The first received byte is 0x55 and the second byte is 0xAC (CRC).

  • RXCRCR = 0xAC
    The SPI peripheral calculated the same CRC value internally.

  • SR = 0x403
    RXNE = 1
    TXE = 1
    CRCERR = 1

The SPI peripheral reports a CRC error although:

  1. The CRC value received from the slave is 0xAC.

  2. The internally calculated CRC value (RXCRCR) is also 0xAC.

  3. The SPI bus waveform confirms the transmitted CRC is correct.

 


 

Why does the SPI peripheral report a CRC error even though:

  • the received CRC byte is correct,

  • the internally calculated CRC value (RXCRCR) matches,

Is there a known condition where CRCERR may still be set although RXCRCR matches the received CRC value?
We also checked the errata sheet of the F7 but nothing appropriate.

 Any guidance on the correct sequence for CRC handling in this situation would be appreciated.
Andy

2 REPLIES 2
KDJEM.1
ST Employee

Hello @andywild2;

 

Could you please give more details about the issue? Which STM32F7 and STM32F4 are you using?

Is the SPI handled by DMA? 

Thank you.

Kaouthar

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Hello Kaouthar,

it is the STM32F767NIH6.
On the F7 side we useHAL 1.3.3 and HAL_SPI_TransmitReceive_IT().
The slave works with DMA, but this does not matter because data from slave is received correct (0x55 plus CRC 0xAC), which we checked on the scope.
Best regards
Andy