Problem with CRC calculation

[F3John]

Hello,
i'am trying to implement a CRC calculation in AI2.
But i dont get the expected result and want to ask if there is an obvious Error

here is the C-Code on the BLE Device:

for (uint8_t i = 0; i < 5 ; i++) { // CRC Check of Header (CMD, Adress, Size
crc = _crc_xmodem_update (crc, buf[i]);
}

uint16_t _crc_xmodem_update (uint16_t crc, uint8_t data) {
int i;

crc = crc ^ ((uint16_t)data << 8);
for (i = 0; i < 8; i++) {
if (crc & 0x8000)
crc = (crc << 1) ^ 0x1021;
else
crc <<= 1;
}
return crc;
}

for the following blocks the CRC should be 0x60 (MSB) and 0x96 (LSB)

[ABG]

I didn't take a deep dive into your code, but I notice one difference between your C code and your blocks:

Thw ^ operator in C is XOR, the exclusive OR operator.
I don't see you doing a bitwise xor in your blocks.

I don't have the capacity to reverse engineer your blocks any further at this moment.

[ABG]

I rummaged around my old projects, and found this old conversion routine.
I don't know if it matches your flavor of CRC16, though.

MODBUS_CRC16.aia (5.5 KB)

P.S. These blocks can be dragged directly into your Blocks Editor workspace.

See A way to group projects by theme
for a demo.

[F3John]

Thank you ABG,

i think i was blind.
One of the XOR Block is an OR Block.

[F3John]

I want to post my Solution for the CRC Calculation.
A second error appeared with larger lists. The CRC Value has to be 16Bit (uint16_t). If not the CRC Value get bigger and bigger until it doesn't work anymore and the crc is wrong.

[ABG]

I have a question about your shift_left function.

Unlike the shift_right function, which uses the floor() operation to clip off bits that have been shifted past the binary point, the shift_left operation does not clip at any left boundary.
In fact, the floor() operation in shift_left is totally irrelevant.

I think shift_left needs further work.

[F3John]

@ABG

I have a question about your shift_left function.

No, it's your shift_left function

Bitwise shift operator?

I love bit manipulation. If you break up the shift function to separate Left and Right variants, you can drop the text ‘right’ or ‘left’ parameter and test, and let AI2 typeblocking help you specify the direction. [shiftRight] [shiftLeft] [shift_sample] [shift_test] Procedure and test blocks are draggable into Blocks Editor, screen shot not draggable.

[ABG]

You are quite right, my earlier post was wrong on the left shift. I have added a postscript to it.
If you are still having trouble with the CRC conversion, point us to the original algorithm source and its language standard.

P.S. Here is my latest idea on the left shift operation for 16 bit unsigned numbers. It probably matches some C standard somewhere.

P.P.S. No, that's wrong too.
I failed to left pad the input binary with zeroes to fit a 16 bit uint.
Hang in there while I fix it.

Okay, here is the corrected version. The idea is that the first 2 inputs of the JOIN make up 16 bits before being padded on the right and having the shift amount clipped off the front ...

[F3John]

Hi ABG,

with my Shift Left i had some Problems. Some of the CRC Calculations were right, some were not.
Today i wanted to debug it.

Now i directly tried your new Shift_Uint16_Left and all CRC's worked.
But with some list i get an Error:

I'am not sure what happend. I dont have Floats in the list.
All floats are multiplied by 10 to get integer
Here is on example of the List:

Edit:
Quick fix with "round" is working fine

[ABG]

@F3John

I don't have Floats in the list.

For good measure, do you want to double check your .Text values and your /256 division?

Those could all be sources of fractional values.

[F3John]

you are right.
i should change it to the right shift procedure