Showing results for 
Search instead for 
Did you mean: 

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


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 width8-bit
Initial value0xC4
Input reflectedNo
Result reflectedNo
Final XOR value0xFF

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.



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? 

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

Sure, Here is some computed packets I have handy:

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

0x7F 0xF50x6F
0x7F 0xFF0xBD

And here is the actual result:

0x7F 0xF50x9E
0x7F 0xFF0x4C

I hope this is what you meant by vectors 🙂


Confirming the expected results via software computation

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

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?



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.

If you feel a post has answered your question, please click "Accept as Solution".

Are all messages 2 byte long?


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.

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

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.