CRC calculation semantics
Object CRC is computed with segmented CRC16 XOR + truncation instead of CRC over serialized bytes
Body
Summary
The current object CRC logic appears to compute multiple independent CRC16 values, XOR them together, and then keep only the low 8 bits.
This is not equivalent to computing a CRC over the serialized object byte stream.
Problem
The logic is effectively:
crc = par_nvm_calc_crc(&id, 2);
crc ^= par_nvm_calc_crc(&size, 1);
crc ^= par_nvm_calc_crc(&data, 4);
rtn_crc = crc & 0xFF;
This does not produce the CRC of:
A CRC over concatenated data must be obtained either by:
- updating a running CRC over the full byte stream; or
- using a proper CRC combine operation that accounts for segment length.
Independent CRC results cannot be combined by simple XOR to get the CRC of the concatenated message.
There is also a second issue here: the code computes a CRC16 and then truncates it to 8 bits. If only 8 bits are stored, the effective check width is only 8 bits anyway, so this weakens error detection compared with storing the full CRC16.
CRC calculation semantics
Object CRC is computed with segmented CRC16 XOR + truncation instead of CRC over serialized bytes
Body
Summary
The current object CRC logic appears to compute multiple independent CRC16 values, XOR them together, and then keep only the low 8 bits.
This is not equivalent to computing a CRC over the serialized object byte stream.
Problem
The logic is effectively:
This does not produce the CRC of:
A CRC over concatenated data must be obtained either by:
Independent CRC results cannot be combined by simple XOR to get the CRC of the concatenated message.
There is also a second issue here: the code computes a CRC16 and then truncates it to 8 bits. If only 8 bits are stored, the effective check width is only 8 bits anyway, so this weakens error detection compared with storing the full CRC16.