2023-08-22 11:58 PM
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.
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.
2023-08-23 12:25 AM
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?
2023-08-23 12:39 AM
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 :)
2023-08-23 01:58 AM
Confirming the expected results via software computation
2023-08-23 02:34 AM - edited 2023-08-23 02:38 AM
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?
2023-08-23 05:58 AM - edited 2023-08-23 05:59 AM
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.
2023-08-23 06:08 AM
Are all messages 2 byte long?
JW
2023-08-23 09:21 AM
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.
2023-08-26 01:55 AM
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.