• Post Reply Bookmark Topic Watch Topic
  • New Topic

CRC calc problem  RSS feed

 
Mike Bates
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am trying to make this code work in Java but when I feed it the byte array it does not work but gives me no error. I think I am over running the int size.

The "crc" is the crc accumulator (16 bits or 2 bytes), "data" is the data or CRC
checksum byte to be accumulated, and "crc_table" is the table of CRC value found in the array
below. The operator "^" is an exclusive-or (XOR), ">> 8" shifts the data right by one byte
(divides by 256), and "<< 8" shifts the data left by one byte (multiplies by 256).

crc = crc_table [(crc >> 8) ^ data] ^ (crc << 8);


This is the code I am using to try to get the crc, loopData is a byte array that equals:



Java Code snippet:


Any direction would be nice. I am still learning and reaching outside my comfort zone which is fun.

Mike

 
Henry Wong
author
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mike Bates wrote:I think I am over running the int size.


Well.... Actually, you may be retaining too much. An int is 4 bytes, and a crc is only two bytes. So, when you shift to the left, the bits that flows into the 3rd and 4th bytes needs to *not* be retained. If you retain it, it will at best, give you a crc that is too big, and at worst, cause an array overflow, during a crc lookup.

Try zaping out the crc high bytes after each calculation.

Henry

 
Mike Bates
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Henry,

I am a bit new, what do you mean by zapping out the high bytes?


Try zaping out the crc high bytes after each calculation.


Thanks
Mike
 
Henry Wong
author
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

 
Mike Bates
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Henry,

Thanks for the replies.

I mocked this up further to test just this case:



I am seeing out of bounds still. I think my mock up is correct and at least I can see I am
seeing the problem, just have to figure out the solution. I am going to verify my crc_table
for values but that was what I was given.

Mike
 
Moojid Hamid
Ranch Hand
Posts: 120
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In your code


the lookup index "(crc >> 8) ^ b" can be as high as 0xFF, since your array length is also 0xFF the maximum index should be 0xFE, it looks like an 0 based vs 1 based index error, java arrays are 0 based.
 
Mike Bates
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think I understand what you are saying, in this case when the index is calculated it starts at 1 instead
of starting at 0. It will never see 0 but will try 0xff which does not exist.

Is there away to change this to be zero based. The example I am using is based on C which I thought
was zero based as well.

Thanks
Mike
 
Henry Wong
author
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

C arrays, Java arrays, and CRCs can take a value of zero. So, zero based arrays is not the issue. If anything, it looks like you have an extra row in your table (row 12 and 13 looks the same).


This is cause by Java bytes. I bet the C version had this as unsigned bytes. What is happening is that when the byte is implicited casted to an int, to do the XOR, it is sign extended, yadda, yadda, yadda, which is not what you want. Basically, the solution is to cast it to an int first, and then zap out the three high bytes... like so...



Henry
 
Mike Bates
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are correct the table was an unsigned short and these are unsigned bytes. Once I removed the duplicate row (bad copy and paste) I was able to get the expected the results. In this case with 99 bytes the last two bytes are a CRC and the result should be 0 and if you just run the first 97 bytes through you get the resulting CRC of 0x53C9 (the last two bytes.)

Thanks for the help.

Mike
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!