How to calculate the error detection capability of a CRC32 algorithm over a memory block?

0
votes

I have encountered a what seems to be a difficult question to answer.

I have implemented a functionality that checks specific ranges of ROM against modified data (by unauthorized user mainly). This is additional to the already active ECC/EDC engines protecting the data from HW random faults (with different algorithms).

Basically at build time, a CRC32 is calculated over the whole Data ROM (defined explicitly in linker file) and stored at specific location. Then during startup of the device the function checks the calculated Data ROM CRC against the one stored at the known location.

The way it is checked is by calculating CRC32 over 4 bytes at a time using microcontroller specific instruction and keeping intermediate results which will be carried until the last 4 bytes are checked, when the final CRC value will be obtained.

I need to justify if the functionality detects enough errors.

How can I evaluate the error detection capability of the CRC32 IEEE 802.3 (with 0x04C11DB7 polynom for example) in this case since the memory block size can have any value with each build, which means that the error detection capability will be different each time the size changes?

Everything that I found until now on this subject takes into account the size of the Ethernet message, which in that case makes sense (since a received message can be marked as valid or not after it is received). But when calculating the CRC over a large memory block (let's assume 1MB or 1GB) I can only know if the data is not corrupted right at the end since the value to check against is obtained after parsing the complete block.

I am thinking of a scenario in which several bits are corrupted in a place of the block and further corruptions in different areas will lead to a "correct" CRC value at the end and thus to undetected errors.

1
crccrc32

1 Answers

0
votes

From this web site table for 32 bit crcs

https://users.ece.cmu.edu/~koopman/crc/crc32.html

The entry is

0x104c11db7 {4294967263,91607,2974,268,171,91,57,34,21,12,10,10,10}

The numbers in the {} are the maximum length message, not including the 32 bits of CRC, versus HD (Hamming Distance) starting with HD=3, or the maximum number of bit errors starting with 2. So all 2 bit errors can be detected in messages up to 4294967263 data + 32 bits of CRC for a total of 4294967295 == 2^32-1 bits. This means there are some 3 bit error patterns that will fail for a total length greater than 91607+32=91639 bits, some 4 bit errors that will fail for a total length greater than 2974+32=3006 bits, ... some 10 bit errors that will fail for a total length greater than 21+32=53 bits, ... .

For your 1 MB case, some 3 bit patterns will fail. For your 1 GB case, some 2 bit patterns will fail.

The CRC you are using has a cyclic period of 4294967295. For a 2 bit error to fail, looking at the message as an array of bits, then if msgbit[i] and msgbit[i+4294967295] are flipped, the CRC will be zero. The odds of this pattern occurring are very low. The math (or more accurately, a somewhat optimized brute force search for failing or passing error patterns) is more complicated for 3 or more bit errors, but the concept is the same.

The odds of such error patterns are low, assuming there isn't a deliberate attempt to mask a change that results in a good CRC.