Is a custom CRC configuration possible for an SPI bus via CubeMX?

[nickglb]

Hello ST community.

I am trying to enable CRC verification to my SPI bus connecting me with an external sensor. Communication works as expected, I am receiving data from the sensor that is valid. However the CRC byte generated by me is incorrect, this also causes valid packets to be discarded.

The SPI bus CRC as well as everything else was set through CubeMX.

Upon investigation I realized my sensor requires some custom values for the CRC:

CRC width	8-bit
Polynomial	0x1D
Initial value	0xC4
Input reflected	No
Result reflected	No
Final XOR value	0xFF

When entering these values on online CRC calculators I see the packets I am receiving from my sensor make perfect sense. It's worth pointing out each packet is 24bits in size, the last 8 bits of it is the CRC checksum.

The 'CRC' subsection under "Computing" in CubeMX allows me to enter most of these settings however it doesn't seem to affect the CRC byte generated at all.

• Am I right to believe there is no way to configure the SPI bus to use these values through CubeMX?
• Is the SPI bus accessing the CRC calculation hardware? If so why are the settings not affecting it?
• Can I configure the `Final XOR value` at all?

At this point I'm fairly confident I have to do the CRC calculation manually invoking the calculator myself, any advise is very welcome.

Thank you in advance.

[Tesla DeLorean]

The SPI has it's own CRC unit, you have to push data through it, and switch modes to output a computation. On reception the feed-thru is expected to divide with a zero remainder.

Not sure it can handle the specifics in this case, and as it's only 3 bytes probably simpler to just to do in software. Do you have a few example vectors? 

[nickglb]

Sure, Here is some computed packets I have handy:

These are the expected results, first column data, second checksum:

0x7F 0xF5	0x6F
0x7F 0xFF	0xBD

And here is the actual result:

0x7F 0xF5	0x9E
0x7F 0xFF	0x4C

I hope this is what you meant by vectors

[Tesla DeLorean]

Confirming the expected results via software computation

[Tinnagit]

You can set your SPI polynomial on CRC Polynomial 
such as 0x1D is X0+X1+X3+X4 to let bit 0-1-3-4 is 1 and equal 0x1D as you want.

for Can I configure the `Final XOR value` at all? - The Final XOR value of CRC always is 0xFF, isn't it?

[TDK]

Your conclusion is correct--It's not possible to change the initial value or the final XOR value for SPI CRC calculations. These are fixed at 0. You'll have to manage it yourself.

[waclawek.jan]

Are all messages 2 byte long?

JW

[Tesla DeLorean]

It's not a 16-bit CRC, it's 8-bit

The CRC check mechanics in the STM32 SPI is a "sums" to zero, ie the good/bad flag is checking if the register is zero or not. Think of a CRC as a long division, typically if you feed the correct CRC back into itself it with zero out the content. This doesn't work here, as the value drops out as 0xC4 when cycled through.

I could build a 16-byte table driven method that can process 4-bits at a time quite efficiently.

It could be done with the programable CRC peripheral, but you'd spend more time on the AHB bus configuring and moving data than it would to do it in software.

[Tinnagit]

yes, I think so that many time many applications, it's not useful because many applications are usually not calculate a data in whole package, it's usually calculate only some part of them or many application are usually not fix package size so it's hard to config DMA to match with every package.