CRCA in CAAM (imx8dx) - wrong results

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

CRCA in CAAM (imx8dx) - wrong results

Jump to solution
1,046 Views
krassimirestoya
Contributor III

I am trying to use CRC accelerator to validate a section of code by checksum, generated by the GHS linker. I access the CAAM via job ring, which works fine, but the resulting checksum is wrong.

. So I decided to test with one simple value in a byte (buffer length =1), here is what happened:

 

The polynomial is 0x10211021 (custom). Start CRC is zero, no swapping, no output mangling

 

Test byte value

Correct result

CRCA Result

0

0x00000000

0x00000000

1

0x10211021

0x10211021

2

0x20422042

0x20422042

3

0x30633063

0x30633063

4

0x40844084

0x40844084

5

0x50A550A5

0x50A550A5

6

0x60C660C6

0x60C660C6

7

0x70E770E7

0x70E770E7

8

0x81088108

0x90299129

9

0x91299129

0x80088108

10

0xA14AA14A

0xB06BB16B

0x81

0x81A181A9

0x30FA22FA

 

 

The calculated value is stable, every time the same, provided the input does not change.

 

Then I decided to test the code from fsl_caam.c that I got from Vincent Aubineau. It produced the SAME wrong results. He is out of office right now.

Can anybody help?

 

0 Kudos
1 Solution
948 Views
Harvey021
NXP TechSupport
NXP TechSupport

Ok, let's try another approach.

I did re-implement the customer's code and here are the results:

Data CRC (Correct polynomial byte ordering LE) CRC (Wrong polynomial byte ordering)
0x0 0x0 0x0
0x01 0x10211021 0x10211021
0x02 0x20422042 0x20422042
0x03 0x30633063 0x30633063
0x04 0x40844084 0x40844084
0x05 0x50a550a5 0x50a550a5
0x06 0x60c660c6 0x60c660c6
0x07 0x70e770e7 0x70e770e7
0x08 0x81088108 0x90299129
0x09 0x91299129 0x80088108
0x10 0xa14aa14a 0xb06bb16b
0x81 0x81a181a9 0x30fa22fa
0xC0 0xFE 0xC0 0xDE 0x5d65486b 0x9089f978


Can you re-try considering correct endianness

 

Best regards

Harvey

View solution in original post

0 Kudos
8 Replies
1,018 Views
Harvey021
NXP TechSupport
NXP TechSupport

Hi @krassimirestoya 

I happened to see that an internal expert was looking at this issue with the following response. hope these below can help you.

A quick loot at the customer code, seems more an endianness issue of the custom polynomial.

By default i.MX8X's CAAM operates in little-endian configuration. The default endianness configuration can be overridden for each individual JR via the PEO bit in the JRCFGR (see SRM).

You can dump the configuration register of the JR assigned to M4 and verify that and write polynomial, read CRC result accordingly.

Or simply consider LE when filling the JD and reading back the CRC result. I mean, set the correct byte ordering when writing the polynomial to buffer (\x21\x10\x21\x10) or as immediate value (0x21102110), and same applies for CRC result. 

 

Best regards

Harvey

0 Kudos
974 Views
krassimirestoya
Contributor III
I reversed the polynomial as suggested, again it works from 0 to 7 - results as expected with the new polynomial and does not work for 8 (presumably 9 and onwards) - the problem is elsewhere, not the endianness
0 Kudos
995 Views
krassimirestoya
Contributor III

This is the lookup table from the SW reference CRC calculation - calculating CRC on one byte is a mere indexing into the table. So how it could work for 0 to 7 and stop working from index 8 onwards, if the problem was in the polynomial endianness?

Lookup Table:
0x00000000 0x10211021 0x20422042 0x30633063 0x40844084 0x50A550A5 0x60C660C6 0x70E770E7
0x81088108 0x91299129 0xA14AA14A 0xB16BB16B 0xC18CC18C 0xD1ADD1AD 0xE1CEE1CE 0xF1EFF1EF
0x12301231 0x02110210 0x32723273 0x22532252 0x52B452B5 0x42954294 0x72F672F7 0x62D762D6
0x93389339 0x83198318 0xB37AB37B 0xA35BA35A 0xD3BCD3BD 0xC39DC39C 0xF3FEF3FF 0xE3DFE3DE
0x24602462 0x34413443 0x04220420 0x14031401 0x64E464E6 0x74C574C7 0x44A644A4 0x54875485
0xA568A56A 0xB549B54B 0x852A8528 0x950B9509 0xE5ECE5EE 0xF5CDF5CF 0xC5AEC5AC 0xD58FD58D
0x36503653 0x26712672 0x16121611 0x06330630 0x76D476D7 0x66F566F6 0x56965695 0x46B746B4
0xB758B75B 0xA779A77A 0x971A9719 0x873B8738 0xF7DCF7DF 0xE7FDE7FE 0xD79ED79D 0xC7BFC7BC
0x48C048C4 0x58E158E5 0x68826886 0x78A378A7 0x08440840 0x18651861 0x28062802 0x38273823
0xC9C8C9CC 0xD9E9D9ED 0xE98AE98E 0xF9ABF9AF 0x894C8948 0x996D9969 0xA90EA90A 0xB92FB92B
0x5AF05AF5 0x4AD14AD4 0x7AB27AB7 0x6A936A96 0x1A741A71 0x0A550A50 0x3A363A33 0x2A172A12
0xDBF8DBFD 0xCBD9CBDC 0xFBBAFBBF 0xEB9BEB9E 0x9B7C9B79 0x8B5D8B58 0xBB3EBB3B 0xAB1FAB1A
0x6CA06CA6 0x7C817C87 0x4CE24CE4 0x5CC35CC5 0x2C242C22 0x3C053C03 0x0C660C60 0x1C471C41
0xEDA8EDAE 0xFD89FD8F 0xCDEACDEC 0xDDCBDDCD 0xAD2CAD2A 0xBD0DBD0B 0x8D6E8D68 0x9D4F9D49
0x7E907E97 0x6EB16EB6 0x5ED25ED5 0x4EF34EF4 0x3E143E13 0x2E352E32 0x1E561E51 0x0E770E70
0xFF98FF9F 0xEFB9EFBE 0xDFDADFDD 0xCFFBCFFC 0xBF1CBF1B 0xAF3DAF3A 0x9F5E9F59 0x8F7F8F78
0x91809188 0x81A181A9 0xB1C2B1CA 0xA1E3A1EB 0xD104D10C 0xC125C12D 0xF146F14E 0xE167E16F
0x10881080 0x00A900A1 0x30CA30C2 0x20EB20E3 0x500C5004 0x402D4025 0x704E7046 0x606F6067
0x83B083B9 0x93919398 0xA3F2A3FB 0xB3D3B3DA 0xC334C33D 0xD315D31C 0xE376E37F 0xF357F35E
0x02B802B1 0x12991290 0x22FA22F3 0x32DB32D2 0x423C4235 0x521D5214 0x627E6277 0x725F7256
0xB5E0B5EA 0xA5C1A5CB 0x95A295A8 0x85838589 0xF564F56E 0xE545E54F 0xD526D52C 0xC507C50D
0x34E834E2 0x24C924C3 0x14AA14A0 0x048B0481 0x746C7466 0x644D6447 0x542E5424 0x440F4405
0xA7D0A7DB 0xB7F1B7FA 0x87928799 0x97B397B8 0xE754E75F 0xF775F77E 0xC716C71D 0xD737D73C
0x26D826D3 0x36F936F2 0x069A0691 0x16BB16B0 0x665C6657 0x767D7676 0x461E4615 0x563F5634
0xD940D94C 0xC961C96D 0xF902F90E 0xE923E92F 0x99C499C8 0x89E589E9 0xB986B98A 0xA9A7A9AB
0x58485844 0x48694865 0x780A7806 0x682B6827 0x18CC18C0 0x08ED08E1 0x388E3882 0x28AF28A3
0xCB70CB7D 0xDB51DB5C 0xEB32EB3F 0xFB13FB1E 0x8BF48BF9 0x9BD59BD8 0xABB6ABBB 0xBB97BB9A
0x4A784A75 0x5A595A54 0x6A3A6A37 0x7A1B7A16 0x0AFC0AF1 0x1ADD1AD0 0x2ABE2AB3 0x3A9F3A92
0xFD20FD2E 0xED01ED0F 0xDD62DD6C 0xCD43CD4D 0xBDA4BDAA 0xAD85AD8B 0x9DE69DE8 0x8DC78DC9
0x7C287C26 0x6C096C07 0x5C6A5C64 0x4C4B4C45 0x3CAC3CA2 0x2C8D2C83 0x1CEE1CE0 0x0CCF0CC1
0xEF10EF1F 0xFF31FF3E 0xCF52CF5D 0xDF73DF7C 0xAF94AF9B 0xBFB5BFBA 0x8FD68FD9 0x9FF79FF8
0x6E186E17 0x7E397E36 0x4E5A4E55 0x5E7B5E74 0x2E9C2E93 0x3EBD3EB2 0x0EDE0ED1 0x1EFF1EF0

 

0 Kudos
972 Views
Harvey021
NXP TechSupport
NXP TechSupport

Hi 

I convey the same from you to expert and get recommendation as like: 

Did you try to set the correct byte ordering in code as advised and it didn't work?

 

Best regards

Harvey

0 Kudos
965 Views
krassimirestoya
Contributor III
See my other reply
0 Kudos
949 Views
Harvey021
NXP TechSupport
NXP TechSupport

Ok, let's try another approach.

I did re-implement the customer's code and here are the results:

Data CRC (Correct polynomial byte ordering LE) CRC (Wrong polynomial byte ordering)
0x0 0x0 0x0
0x01 0x10211021 0x10211021
0x02 0x20422042 0x20422042
0x03 0x30633063 0x30633063
0x04 0x40844084 0x40844084
0x05 0x50a550a5 0x50a550a5
0x06 0x60c660c6 0x60c660c6
0x07 0x70e770e7 0x70e770e7
0x08 0x81088108 0x90299129
0x09 0x91299129 0x80088108
0x10 0xa14aa14a 0xb06bb16b
0x81 0x81a181a9 0x30fa22fa
0xC0 0xFE 0xC0 0xDE 0x5d65486b 0x9089f978


Can you re-try considering correct endianness

 

Best regards

Harvey

0 Kudos
902 Views
krassimirestoya
Contributor III
My bad, I must have done something wrong on my initial endianness change, now I reapplied it and everything is fine, thanks a lot!
921 Views
krassimirestoya
Contributor III

Hi, The first columns is correct, can you show me what you do, because simply changing the byte order in the polynomial did not work?

Tags (1)
0 Kudos