2
votes

I am using a poorly documented system where a CRC16 is needed in a structure that I need to modify. Modification will not take effect unless I provide the correct checksum.

Technical support has indicated that they were using the standard CRC16, but using the CRC16 CCITT would not give me the result.

I have a small snippet of data and the checksum that it is supposed to have.

Can someone help me find the proper CRC16 parameters (polynomial, initial value) that will match my data set?

Another thing. On the platform in question, addresses are organized with 16 bit words for each address, so I tried both the original byte order and the reversed byte order.

Data Set #  1
crc         0xb19f
data @b306: 7a b1 74 44 9f 84 74 5b  
length      8 bytes

Data Set # 2
crc        0x447b
data @0036 00 43 e2 05 5b 03 00 02 00 16 00 00 00 00 00 00
           00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
           12 c0 00 00 00 07 f7 ff 3f e5 ff ff 3f ff 75 30
           3a 98 00 01 00 9d 00 0f 00 09 00 0a 00 00 00 00
           00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
           00 00 00 00 00 00 00 00 00 00 00 00 00 0a 80 0f
           47 44 09 6d 0a 35 09 c4 f0 00 00 40 10 00 00 01
           07 d0 27 10 00 00 ff 38 00 5a ff 06 0a fd 00 05
length     128 bytes

Knowing what I know now, I thing I choose poorly when I selected the organization that does not provide much technical support, I know that now.

[EDIT:] Processor is ~ 8051 but not sure about endianness. My test code tests for both types of endianness as a matter of course.

[EDIT:] I found this other question helpful: CRC16 and data communications

2
Firstly, CRC16 is not the same as CRC16 CCITT - so why would you expect it to work? Secondly, this page says broken implementations are common, so you might want to find one or two that generate different results from whatever correct implementation you find, and see if any of them match what your product's using. Thirdly, why the [c++], [c] and [embedded] tags? -1 for dishonestly attracting an audience! - Tony Delroy
@Tony D, sorry about the C++ and C tag, I removed them. As for embedded, this is honest, an embedded platform, which I can not name for fear of shaming them for providing such poor support. - Bamaco
@Bamaco: my -1 gone then (though embedded can be true while being ostensibly irrelevant to the question as posed), but if they've used this CRC approach widely throughout their software, naming them might be the most practical way to get actual experience and help.... - Tony Delroy
@Bamaco Yup - I feel for you - ugly situation. May end up having to "social engineer" the extact CRC code/algo out of them somehow.... Good luck! - Tony Delroy
Try entering you data into an online CRC Calculator such as this one. If you can cut and paste your appropriately formatted data into the field then it will automatically calculate a variety of CRC algorithms. - kkrambo

2 Answers

1
votes

The code linked in your own answer seems to have a lot of unrelated code in it, but the 16 bit CRC function mentions two polymonials:

x^16+x^5+x^2+1.
x^16+x^12+x^5+1

but the comment that mentions these suggests that the author has not realised that one is simply the reverse version of the the other which may be why there is confusion over the documentation. Either way it is the CRC-16-CCITT polynomial (as used in X.25, V.41, HDLC, XMODEM, Bluetooth, SD, many others; known as CRC-CCITT). That is not to say that it is implemented correctly of course or that the comment even is correct.

It looks like a ragged collection of code from multiple sources. You have to wonder about a vendor relying on code and algorithms of unknown provenance and obvious confusion!

Incidentally, the 32 bit CRC in the same code uses the CRC-32 polynomial (as used in ISO 3309, ANSI X3.66, FIPS PUB 71, FED-STD-1003, ITU-T V.42, Ethernet, SATA, MPEG-2, Gzip, PKZIP, POSIX cksum, PNG, ZMODEM).


Later edit:

I have found it, using this site: http://www.zorc.breitbandkatze.de/crc.html and a great deal of trial and error. Unfortunately the site takes data in ASCII, so I converted the 8 byte sample to text using http://www.rapidtables.com/convert/number/hex-to-ascii.htm (which yields "z±tDt[" - note that the string contains some non-printing characters, but copy&pasting them from the site appears to include them as it reports 8 bytes whereas the string here is 6 - do not copy and paste from this post).

Any how the configuration that yields the result given in your data sample is as follows:

Screenshot of www.zorc.breitbandkatze.de/crc.html Set-up as follows:

  • click CRC-CCITT,
  • with the "initial value" set to FFFF, click the "Convert!" (to "non-direct" which transforms the value of 84CF),
  • set "final XOR" to FFFF,
  • check "reverse data bytes",
  • enter data in ASCII,
  • click "Compute!" button.
0
votes

It turns out that I got the reply from the embedded chip manufacturer.

The code links here

Does not look like a standard CRC16 to me and I am not surprised that reveng was unable to determine the CRC algorithm in use.