Support verifiyng C CRC8 implementation - c

Question

have made some test on a crc calculator I have written based on dallas crc8 applied in 1-Wire, it uses 0x8c poly. I am testing it adding 1, 2 and 3 bit errors on a 15 bytes string (adding bit errors also to the crc itself). The pasted implementation is unable to identify 2, 2bit errors and 9, 3 bit errors...
static inline uint8_t roll(char input_byte, uint8_t crc) {
for(uint8_t i = 8; i; i--, input_byte >>= 1) {
uint8_t result = (crc ^ input_byte) & 0x01;
crc >>= 1;
if(result) crc ^= 0x8C;
}
return crc;
};
static inline uint8_t compute(const uint8_t *input_byte, uint16_t length) {
uint8_t crc = 0;
for(uint16_t b = 0; b < length; b++)
crc = roll(input_byte[b], crc);
return crc;
};
Fiddling with the code I have noticed that removing & 0x01 cause a huge gain in accuracy whatever value data has (trying with different types of string):
static inline uint8_t roll(char input_byte, uint8_t crc) {
for(uint8_t i = 8; i; i--, input_byte >>= 1) {
uint8_t result = crc ^ input_byte;
crc >>= 1;
if(result) crc ^= 0x8C;
}
return crc;
};
static inline uint8_t compute(const uint8_t *input_byte, uint16_t length) {
uint8_t crc = 0;
for(uint16_t b = 0; b < length; b++)
crc = roll(input_byte[b], crc);
return crc;
};
With the posted modification I get no 1, 2 or 3 bit errors with always 100% accuracy for the range I need that is 0-15 characters or 0-120bits
Is there someone could help me understanding what is happening here?

Answer 1

I believe there's a flaw in your test methodology. According to my testing, the original implementation detects all 1, 2, and 3 bit errors, and 99.2% of 4 bit errors. Your proposed alternative almost always generates the exact same result (0xf7). This is to be expected since crc ^ input_byte will almost always be non-zero.
Hence, your implementation is equivalent (most of the time) to:
static inline uint8_t compute(const uint8_t *input_byte, uint16_t length) {
uint8_t crc = 0;
for (int i = 0; i < 15; i++) {
for (int j = 0; j < 8; j++) {
crc >>= 1;
crc ^= 0x8C;
}
}
return crc;
}
which indeed generates the value 0xf7.
I believe the flaw in your test is that it assumes that a crc match is a good thing. On the contrary, if the crc on the original string is the same as the crc after injecting bit errors, that's bad (the crc generator did not detect the error).