cancel
Showing results for 
Search instead for 
Did you mean: 

SPI crc error every time

STM-aspirant
Associate

Hello everyone,

 

I have enabled an spi1 port on a STM32G473CET6 as a slave and am using a raspberry pi as a master.

STMaspirant_0-1732566292501.png

I have verified with known packets to ensure I have implemented the correct crc algorithm on the raspberry pi both in transmission and reception. It's quite confusing because they are correct, in both directions the calculated and expected crc is the same. However, no matter what the stm32 is calling HAL_SPI_ErrorCallback(SPI_HandleTypeDef *hspi) for a crc error. I verified thoroughly the CRCs and even echoed the same packet to check. This is printed by the stm32.

STMaspirant_1-1732566526918.png

I also checked this website for the crc implementation.

STMaspirant_4-1732567303619.png

 

The only the potential lead I can find (here) is that I have to flush the buffer which is reading the registers RXCRC and DR as I understand.

STMaspirant_3-1732567224523.png

I have tried this and still without fail I get a crc error. Between transactions I also reset the SPI port so that it doesn't get stuck in error. Does anyone have an idea? I will also leave the registers below to check.

STMaspirant_5-1732567485765.pngSTMaspirant_6-1732567497527.png

STMaspirant_7-1732567510795.png

 

Thank you in advance

 

2 REPLIES 2

Does the STM32 side have the CRC register go to zero when the 0x31,0x00 received bytes are fed thru?

The check is that the CRC zero's not that there's a "match"

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

When you say fed through you mean when the callback is entered? The photos of the registers are of when the stm32 had just entered it. I've tried a few more times while sending and receiving a known packet because as far as I can tell there is no way to know what the hardware rx crc is without calculating it independently.

 

In any case, the RXCRC and TXCRC are always the values that I expect, not zero.

 

I have also tried dummy reading SPI->DR and SPI->TXCRC and SPI->RXCRC to flush them.

 

Here's a photo of some tests I've made where I'm printing directly from the SPI registers. I also verified in debug mode.

STMaspirant_0-1732614396504.png