Incorrect CRC value from software and harware SPI CRC

[WCarey]

Hi, 

In my application, I'm using SPI (SPI1, a full feature set instance) with CRC enabled, on STM32H563ZI, with the configuration as:

I have a CRC implemented based on CCIT standard, which I call 'software CRC'

I see different CRC values for the same bytes of input from the micro and software CRC. 

Fig1. Software CRC which is 0x8B2C (the last 2 bytes shown in Logic Analyzer, with msb first configuration)

Fig2: CRC from ST which is 0x5D0C for the same input.

My software CRC calculation is not wrong and is verified using this calculator (https://crccalc.com/) which yields 0x8B2C.

Kindly help in understanding why the 'hardware' CRC is different from 'software'.

[waclawek.jan]

It's hard to analyze when the message is long. Try one byte first.

How exactly is SPI set up (post perhaps read out content of registers) and how exactly do you feed data to it?

JW

[WCarey]

Apologies for the late reply. I could not get the registers content as I'm having trouble viewing the 'Registers Window' in Keil. 

Here's my SPI configuration.

[WCarey]

I use UART to send/receive data to/from my master from a terminal

The master then talks to slave via SPI

[WCarey]

I have another question. I use HAL_SPi_TransmitReceive_DMA APIs for SPI Tx & Rx i.e during Tx, *pRxData is dummy data and vice versa for Rx. 

So, I get a CRC error  during Tx as my TransmitReceive API checks for Rx CRC of dummy Rx data. How to handle this?

[waclawek.jan]

Sorry, I don't know, I don't have experience with CRC in SPI.

JW

[WCarey · Accepted solution]

The CRC Polynomial for my software CRC calculation is 0x1021. However, in SPI CRC calculation I had to use 0x11021 to get the same result as software.

[waclawek.jan]

This is surprising; although the description in RM may hint at it (that description is rather messy).

Thanks for coming back with the solution.

JW