Can the STM32 CRC peripheral be made to work with the CRC-15_CAN polynomial?

[DHase.1]

Can the CRC for the ADBMS1818 (and other Analog Devices BMS parts) be generated using the STM32 CRC peripheral?

The ADBMS1818 datasheet shows a 15 bit polynomial for the CRC as--

x 15 + x 14 + x 10 + x 8 + x 7 + x 4 + x 3 + 1

Other sources call this a CAN-15-CRC polynomial, e.g., the Wikipedia article Cyclic redundancy check.

Wikipedia lists this polynomial as "even", and the Ref Manual for the STM32L431 says that the CRC peripheral does not work for even polynomials. However, it is not clear as to the exact definition of what Wikipedia and ST are using for "even." So, it is not clear that this polynomial can be handled with the 'L431 CRC.

However, if the problem is odd/even, there might be some tricks to make it work, e.g. reversal of the polynomial with a zero added, but I'm not sure if that is possible. I've made some attempts that have not been successful.

Finally, the datasheet has an example of software routine for generating the CRC. It uses a polynomial representation of 0x4599. However, the Wikipedia and its references show it as 0xC599 (16b!).

For software implementation the usual table lookup is probably satisfactory, however if it is possible to make use of the 'L431 hardware it would save the memory space for the table and provide a small improvement in computation time.

[waclawek.jan]

> I was not familiar with the term "intrinsics."

It's ARM's term. I don't like it. I don't like ARM's terminology in general, but that's all I can do about it.

Thanks for sharing the code and results.

> table lookup by nibbles the slowest

Yet it's the most portable. A very nice illustration of the principle, where efficiency goes straight against flexibility (whatever both of these mean).

> This suggests that if inline instructions overtake the CRC peripheral, wait states would be generated.

Probably so, especially considering it in context of older incarnation of the CRC module, where there was no such buffer and waitstates were explicitly said to be generated. ST might've formulated more clearly, but clear documentation is not ST's forte.

In pure asm, you could've tried to "overload" the CRC by loading several words of data into several registers beforehand, and then dump it on CRC at once. In the case I am talking about in that gotcha, the problem is exactly this: both values for control register and the first data are loaded into registers beforehand (by the C optimizer, given some previous sequence of events), and then dumped at CRC module immediately after each other. The waitstate mechanism in 'F4 obviously does not account for this. I wonder, whether in 'L4 this potential problem has been already solved.

JW