CRC-8 algorithm in m3/y

[AMP3R]

Does anyone know what crc-8 algorithm is used in M3/Y? I've tried different 20 and none of them are similar to Tesla's.
I'm trying to emulate the steering column switch.

[uhi22]

Other OEMs use a combination of CRC and a table of magic bytes (with 16 entries). The counter (0 to 15) would select a row in the table. The content of the table can be added to the byte stream for the CRC. If we would have more data (also changing some payload data it should be possible to reverse-engineer the algorithm.

Edit: What I wrote is public available as E2E Profile 2 in the Autosar E2E specification, https://www.autosar.org/fileadmin/stand ... otocol.pdf

[AMP3R]

I have already almost done this table of bytes.

[uhi22]

Yeah, great. This looks like the "pragmatic" approach. Just putting the CRC into a lookup table, and having different tables for different message payload. And then selecting the right table based on the payload. With this approach, no real CRC calculation is necessary, because the CRC can be taken directly from the table. Ok so far, as long as the number of combinations is small (e.g. in the case that the message only contains buttons, and maximum one button is pressed at a certain time).

The more flexible approach would have only *one* table with 16 entries, and calculate the CRC over the payload and magic byte.

It is possible to find out the CRC polynom, if we have some messages where single bits are set and reset, and where the message counter (and so the magic byte) is identical. Each bit in the message leads to a characteristic change in the CRC, and this reveals the polynom. The approach was successfully used here: https://knx-user-forum.de/forum/%C3%B6f ... post626281

When the polynom is found, a set of 16 messages with identical payload and counter values from 0 to 15 can be used to calculate the 16 magic bytes.

[AMP3R]

Since other car manufacturers use prepared CRC arrays, why am I worse?

In general, what is easier for a microcontroller, to calculate CRC in real time or to take ready-made ones from arrays?

[uhi22]

Both is fine Tables need ROM space, calculation needs runtime. Depends on the project which of both is more important.
But there are two different layers we are mixing up here:
1. The CRC calculation itself: The CRC calculation function can use either tables or loops with bit operations.
2. How to find the value for CRC field in the CAN message. This can eigher use
(a) the CRC function (see 1), or
(b) it can use pre-calculated table entry which needs to be available for each possible combination of payload data.

The 2b explodes, if we have more than a few bits in the payload. E.g. 8 independent buttons combined with 16 values of the counter would need 256*16=4096 table entries.

[projectgus]

I've had good luck using CRCBeagle in the past: https://github.com/colinoflynn/crcbeagle/ - fed enough samples of data and CRC, it should be able to calculate init/poly/xor.

Of course if it's something like the Autosar algorithm mentioned by uhi22 then it won't be able to recover that.

[AMP3R]

Both is fine Tables need ROM space, calculation needs runtime. Depends on the project which of both is more important.
But there are two different layers we are mixing up here:
1. The CRC calculation itself: The CRC calculation function can use either tables or loops with bit operations.
2. How to find the value for CRC field in the CAN message. This can eigher use
(a) the CRC function (see 1), or
(b) it can use pre-calculated table entry which needs to be available for each possible combination of payload data.

The 2b explodes, if we have more than a few bits in the payload. E.g. 8 independent buttons combined with 16 values of the counter would need 256*16=4096 table entries.

Then in my case with gear selector it is better to use arrays with CRC.