STM32H7 SPI 32BIT CRC Confusion

[kip18]

Hello, I am having an issue implementing a 32 bit CRC 0x04CDB117

I am quite confused by the documentation on how to set the a 32 bit CRC
I don't understand section 53.5.3 on the most significant bit in in CRCPOLY must be larger than the data size.
I don't understand what register CRC33-17 is referring to.

Any help or clarification would be appreciated.

Thanks

[TDK · Accepted solution]

If you have a 32-bit CRC, set CRCPOLY register to 0x04CDB117 and set CRC33_17 bit in the CR1 register.

(Please include the full chip part number in the future. There are many different "STM32H7" chips.)

[kip18]

Thanks, this clears up my confusions. My CRC errors must be something else.

Was referring to STM32H742 and STM32H755

[Tesla DeLorean]

Not sure, what patterns have you generated / expect?

The patterns typically take the for x^32 + .. + 1, which is arguably 33-bit, in other implementations this is implied, or hidden in the hardware.

The CRC33_17 seems to relate to how it's managing the HW, and potentially 16-bit writes to the data register, and interstaging values between bytes/words.

https://www.st.com/resource/en/reference_manual/rm0468-stm32h723733-stm32h725735-and-stm32h730-value-line-advanced-armbased-32bit-mcus-stmicroelectronics.pdf

>>Hello, I am having an issue implementing a 32 bit CRC 0x04CDB117

Yeah, expand on this a little. Done what? What protocol / peripheral specifically are we talking about? Left/Right shifting?

What kind of transaction?

[kip18]

I have a working implementation with 16 bit frame length and I am trying to go to 32 bit length.

I thought it would be as simple as increasing the DMA from halfword -> word and changing the CRC to be 32 bit but I am running into CRC errors still so I assume my 16 bit implementation is more fragile than I expected.

Just communicating from one STM32H755 -> STM32H742
Transaction is just a blob of 128bytes full duplex
These are my working 16 bit settings

This is my 32 bit implementation which I think is correct based on the initial reply and my issue lies in my implementation and perhaps transmission lengths, still investigating. Thanks

[TDK]

Could be an endian-ness issue and/or interpretation issue.

Perhaps try it on 4 bytes of data which can easily be verified through one of the online CRC calculators.

Show what data you're calculating it on, what you get, and what you expect.