CRC 32bit

[Norbert_B]

And again we encounter a severe issue with what you, some others and different code have:

You state two different checksums, stating 117 bytes. Using the online calculator results in a different CRC32 (again): B8847F7. And again, the CRC32 VI i linked returns the same CRC32 as the online calculator.

One note: The online calculator says 234 bytes, which is the same as the LV implementation expects because of the typecast string to [U8].

There are so many different algorithms around, perceptions and expectations that you have to step back. Analyze what thec controller really does as CRC. The implementation of the controller is definetly NOT standard CRC32 as it uses a completely different mask!

Norbert

EDIT: Please note that what i tell you now is exactly what Tim (crossrulz) already posted as first reply to this post!

[jamiva]

---

@jay0909 wrote:

Hi,

          The maximum number of bytes is 117. below is the frame. 

1500 0000 73A1 0000 0468 0000 0000 0000 0042 02F5 C342 0400 007F FFFF FF3E E76C 8B3C 1374 BC42 4AF0 A444 2566 6642 480F 5C43 6D44 DC42 9CCC 9B42 9ECE 4442 9EEE DAC0 D9D1 F6BE CE63 BBBF 1A27 B1BF 84A4 9E3E A9F4 383E AC67 9E3E AC11 7A43 6C00 8343 6B87 F043 6B9B 23FF FFFF FF7F FFFF FF7F FFFF FF

CRC of the above frame : 4705 C23C 

Calculation from your program is : EB6E7573. 

---

I get EB6E7573 as you did. This does not match up with the expected value. So... what caused the mis-match?? 1) is it the CRC algorithm or 2) is there an actual error in the transmitted data?

If an algorithm calculates the correct CRC for 2 random data data sets, there is a very high probability that the algorithm is correct. I would guess it is the last data set you provided.

Try reading in a few more SMALL sequences to verify that the CRC is working as expected. If you get some matching CRCs and a few non-matching CRCs, then you can assume you have a noisy communication link. If ALL the small sequences are matching, try increasing the length of the sequences until errors are seen. You may be dropping bits.

[jay0909]

Hi,

      But the algortihm gave error crc for below two frames with length =17 bytes

1) whole frame : 1C0000009DE50200040400000000000000B6CE2D67

CRC of the above frame: B6CE2D67

Calculated CRC : 356B73A2 from the program .

2 ) whole frame : 1C000000B0B80700040400000000000000

CRC of the above frame: 226F9471

Calculated CRC : 9D0351B5 from the program .

[jamiva]

Two things

First: in example 1)  you don't take the CRC of the CRC. Drop the CRC and just use "1C0000009DE50200040400000000000000". Then the CRC is B6CE2D67 and matches the expected value.

Second: look at your very first post (copied below). You state that the frame CRC is 9D0351B5 and your calculated one is 226F9471. So what is it?? I calculate the 9D0351B5 CRC

---

@jay0909 wrote:

Hi,

      i am communicating with stm 32 via UART. The frame i receive is      "1C000000B0B80700040400000000000000" and the CRC of the frame is " 9D0351B5". its not matching the calculation of the crc which i do, the calcuated crc is " 226F9471" . I tried the calculation with python and other sources calculated crc works fine. If anyone how to solve, pleas elet me know. 

---

[jay0909 · Accepted solution]

Hi,

          Finally i solved the CRC issue, THe problem was not with the CRC calculation. Its a silly mistake when reading the data from uart. The problem was wrong concatenating the string while reading the data so the data was totally swapped. 

Thanks everyone for the support

[billko]

Don't you hate when that happens?

Another example of, "I love programming because the program does exactly whait I tell it to do; I hate programming because the program does exactly what I tell it to do."  😄