Using the Hardware CRC for a CRC-8 calculation

[STM_User_1234]

Hi together,

I am communicating over different interfaces and these are from different suppliers. There it is used the CRC-8 algorithem to secure the the communication data.

I have two cases, in both we use a table to realize the crc calculation, now I try to replace the software calculation with the hardware-crc unit of the STM32-controller.

In one case it works, there is the calculation we used so far like this:

The table-value is found over xoring the actual value with the new data byte as index of the table.

internalCrcValue is initialzed with 0x00.

internalCrcValue = crcTable0x19B[internalCrcValue ^ newValue];

In the other case with the same table but a different calculation I find no setting which fits for the Hardware-CRC unit.

The table-value is found over xoring the actual value as index for the table with the new data byte..

crc is initialzed with 0x00.

crc = crcTable0x19B[crc] ^ newValue;

The second algorithem is a little bit strange for me and I find no solution to get the correct crc value from any CRC-calculator in the internet.

Polynom for the HARDWARE-CRC is 0x9B, no reflected in- or output, initial value is 0x00.

Does anyone know this procedure?

Thanks

[TDK]

> crc = crcTable0x19B[crc] ^ newValue;

This is not in the form of a CRC calculation and can't be done in the CRC peripheral. You'll have to do it in software.

Probably someone who didn't know what they were doing wrote it, saw that it calculates similar to a CRC, and called it a day. But it's not a CRC.

[Tesla DeLorean]

>>Does anyone know this procedure?

Well I understand the mechanics, since before the dawn of the modern Internet, and I don't need on-line calculators. Posted examples / threads here using the STM32 HW to do 15-bit and 24-bit CRC..

It could be table driven, and in this fashion, as it's 8-bit it becomes a sequence, no need to rotate.

Thing with 0x9B (10011011) is that it could arguably shift in either direction.

You've got an assortment of known working patterns for your two pieces of equipment?

[Tesla DeLorean]

>> crc = crcTable0x19B[crc] ^ newValue;

Yeah, I don't like that form, but looks somewhat commutative..

>> internalCrcValue = crcTable0x19B[internalCrcValue ^ newValue];

This would work.

Although I'm not convinced the HW can do it much faster, got at least 4-cycles on the bus for each byte or word. And the HW is not thread-safe / interruptable

[STM_User_1234]

Thanks for your replies, so i will keep the method in software.

I have to keep the second algorithm because the terminal I have to communicate with, is mandotory and I can not change the algorithem which is some years old :-).

You've got an assortment of known working patterns for your two pieces of equipment?

How does you mean this?

I know that by hardware CRC it would not be faster but we are checking out all our CRCs in the project and both we would keep like it is, but I want to learn something about the used algorithems.

Thank you to both for the informations.

[Tesla DeLorean]

>>How does you mean this?

Some example test vectors for each.. so one might test / validate potential solutions.

[STM_User_1234]

Hi again, no so far no test vectors were made but of course I have to do so if both the real CRC and the pseude-CRC are functional so far. When I know more I will give you feedback.

See you.