topic Re: CAAM endianess for computed CRC in i.MX RT Crossover MCUs

CAAM endianess for computed CRC

mastupristi — Sat, 21 Mar 2026 21:56:21 GMT

Hello,

Using the CAAM example from SDK 25.06.00 as a starting point, I created the attached project.
In this test, I have an array of 16 elements containing the numbers 0 through 15, and I calculate the CRC for progressively larger portions of this array using two different CRC algorithms.

I calculate the first 16 values using these CRC parameters:

Poly = 0x1edc6f41
XorIn = 0xffffffff
ReflectIn = True
XorOut = 0xffffffff
ReflectOut = True

This means that the mode is kCAAM_CRC_ModeDefault.

These are the expected CRC values and the actual CRC values:

num elements in the array	expected crc	computed crc
1	0x527d5351	527d5351
2	0x30af4d1	30af4d1
3	0x92fd4bfa	92fd4bfa
4	0xd9331aa3	d9331aa3
5	0x2425b106	2425b106
6	0x41098514	41098514
7	0xa359ed4c	a359ed4c
8	0x8a2cbc3b	8a2cbc3b
9	0x7144c5a8	7144c5a8
10	0x22c2131	22c2131
11	0xfb159dfa	fb159dfa
12	0x5383aaba	5383aaba
13	0xc69a45da	c69a45da
14	0x55a24c54	55a24c54
15	0x68ef03f6	68ef03f6
16	0xd9c908eb	d9c908eb

They all match, and I believe they would do so for any input I might provide. From this, we can conclude that the CRC calculated by CAAM is stored in memory in little-endian format.

Now let's make just a small change to the algorithm:

Poly = 0x1edc6f41
XorIn = 0xffffffff
ReflectIn = True
XorOut = 0xffffffff
ReflectOut = False

This means that the mode is kCAAM_CRC_ModeDOS, the DOS bit is 1.

Let's check the results

num elements in the array	expected crc	computed crc
1	0x8acabe4a	4abeca8a
2	0x8b2f50c0	c0502f8b
3	0x5fd2bf49	49bfd25f
4	0xc558cc9b	9bcc58c5
5	0x608da424	24a48d60
6	0x28a19082	8290a128
7	0x32b79ac5	c59ab732
8	0xdc3d3451	51343ddc
9	0x15a3228e	8e22a315
10	0x8c843440	4034848c
11	0x5fb9a8df	dfa8b95f
12	0x5d55c1ca	cac1555d
13	0x5ba25963	6359a25b
14	0x2a3245aa	aa45322a
15	0x6fc0f716	16f7c06f
16	0xd710939b	9b9310d7

The endianess is different. It's as if, in this case, they were saved in big-endian format.

All it took was the DOS bit, which is described in two different ways in the manual

At one point, DOS is described as bit-swap, while shortly thereafter it is described as bit/byte swap.

The question is: How can I ensure that the calculation is consistent regardless of the DOS bit and, above all, consistent with the expected value?

In the project you will find the bash script test.sh to compute crc a get the expected values.

best regards

Max

Re: CAAM endianess for computed CRC

Kan_Li — Mon, 23 Mar 2026 06:26:46 GMT

Hi @mastupristi ,

The description for DOS in Table 6-212 is correct, then it is enabled, the output value is bit- and byte-swapping. It can also be interpreted from your results, For example , when DOS is not enabled, the CRC is 0x527d5351, when DOS is enabled, the result would be 0x8acabe4a if it just enables bit-swapping, while it is bit- and byte-swapping, so the result is 0x4abeca8a.

Hope that makes sense,

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

Re: CAAM endianess for computed CRC

mastupristi — Mon, 23 Mar 2026 07:56:54 GMT

Hi @Kan_Li

You didn't answer the question:

regards

Max

Re: CAAM endianess for computed CRC

Kan_Li — Tue, 24 Mar 2026 07:46:00 GMT

Hi @mastupristi ,

As I mentioned before, referring to Table 6-212, for the output, the bit swapping and byte swapping options are enabled/disabled together, so there isn't a way to do one, but not the other. so it is not possible to have an output with only bit swapping is enabled.

Have a great day,
Kan