tag:blogger.com,1999:blog-4172950626830217643.post7318092859499315712..comments2024-03-28T03:20:54.405-04:00Comments on Better Embedded System SW: Seven Deadly Sins of CRCs and ChecksumsPhil Koopmanhttp://www.blogger.com/profile/11849599272360094243noreply@blogger.comBlogger11125tag:blogger.com,1999:blog-4172950626830217643.post-71338068507976588642022-08-18T20:28:01.773-04:002022-08-18T20:28:01.773-04:00Corruption of the CRC field itself is accounted fo...Corruption of the CRC field itself is accounted for in the HD. The HD accounts for any combination of codeword bit corruptions, including both the dataword and the Frame Check Sequence (CRC value)Phil Koopmanhttps://www.blogger.com/profile/11849599272360094243noreply@blogger.comtag:blogger.com,1999:blog-4172950626830217643.post-20285714833715777172022-08-18T20:13:53.876-04:002022-08-18T20:13:53.876-04:00What are the effects of corruptions in the CRC its...What are the effects of corruptions in the CRC itself?<br /><br />I'm assuming that a single bit corruption in the CRC makes all HD promises invalid.<br /><br />If that's the case, how does this affect the error detection analysis?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4172950626830217643.post-52872608277876108152020-10-08T09:20:39.483-04:002020-10-08T09:20:39.483-04:00Thanks for the story. This sort of issue is why m...Thanks for the story. This sort of issue is why many protocols start with a length field in a known place.Phil Koopmanhttps://www.blogger.com/profile/11849599272360094243noreply@blogger.comtag:blogger.com,1999:blog-4172950626830217643.post-75118567567950127892020-10-07T23:23:54.961-04:002020-10-07T23:23:54.961-04:00Anecdote on length field importance and rule 6: Re...Anecdote on length field importance and rule 6: Recently used CRC16-CCITT for an embedded design. The packet length is known after there is a silence in the line.<br />I Assumed CRC would magically detect errors, wrong lengths and the possibility of an error was anything but remote... Turns out line silence isn't always properly detected and therefore 0x00 ends up sometimes in the packet as the last byte (erroneously).<br />Now check this out: ALL and EVERY valid packet with CRC16-CCITT with any extra (bogus) 0x00 at the end has also a valid CRC and passes the CRC check!!!!!!!!<br />Example:<br />D: DATA Byte<br />X: CRC Byte 1<br />y: CRC Byte 2<br /><br />DDDDXY <- XY is the valid CRC for DDDD<br />DDDDXY0 <- Y0 is a valid CRC but X (CRC Byte 1) will be taken as data!!<br />DDDDXY00 <- 00 is a valid CRC but XY will be taken as data!!<br />DDDDXY000<- 00 is a valid CRC but XY0 will be taken as data!!<br />and so on...<br /><br />At first I thought I had found a 1 in a 65536 test case (at least) and not so bad. Fortunately I wondered how likely was it and created a montecarlo program to find out, ohh was I surprised that every time it was the case!<br /><br />I guess I will have to change my algorithm<br /><br />Thank you for the information you have provided to the communityLuisFhttps://www.blogger.com/profile/09558301611308046926noreply@blogger.comtag:blogger.com,1999:blog-4172950626830217643.post-24155725887925725492014-03-06T01:42:47.102-05:002014-03-06T01:42:47.102-05:00Guess what happens in IEEE 802.15.4 / Zigbee.... l...Guess what happens in IEEE 802.15.4 / Zigbee.... last I checked - no CRC or checksum protection of a leading length field. Nobody I mentioned this to seemed to find it a problem. It's a disaster waiting to happen.<br /><br />The most robust protocols get around these kind of problems by use of things like illegal sequences (coding or symbol violations) to insert start / end of frame markers, and then use things like bit stuffing to ensure such symbols can never appear inside a valid data frame (eg HDLC). <br /><br />The problem is always one of distinguishing control fields in the presence of bit errors. Ignoring the issue does not make it go away. Of course, redundant coding (and thus decent HD) can aid, but its not nice for bandwidth - you don't get something for nothing.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4172950626830217643.post-6631060821282961732013-07-10T08:20:15.402-04:002013-07-10T08:20:15.402-04:00It does make the whole packet HD=3, and that is pr...It does make the whole packet HD=3, and that is probably why some protocols use the same HD for header protection as packet body protection.<br /><br />I don't know why USB did it that way. But the obvious argument would be that the header is a smaller target to hit with random bit errors than the packet body. You might, for example, argue that a particular random independent bit error rate HD=3 on the header is good enough because it is very unlikely to get 3 errors there, while HD=4 is necessary for the packet body because the body is so big that 3 errors will happen often enough there to be a problem. To make this argument for your system you'd need to decide that random independent bit errors is the right fault model for your system, and then do the probability math to decide if number of undetected header errors is low enough to be acceptable to you.<br /><br /><br />Phil Koopmanhttps://www.blogger.com/profile/11849599272360094243noreply@blogger.comtag:blogger.com,1999:blog-4172950626830217643.post-82653904317031826932013-07-09T19:14:59.833-04:002013-07-09T19:14:59.833-04:00Just one last question... The 'CRC on the mess...Just one last question... The 'CRC on the message header' approach, I noticed on USB that the header CRC is HD 3 yet the data is HD 4. I've seen this elsewhere as well. Is there some logic behind why the header can be weaker? This makes the whole packet HD 3 effectively..<br /><br />Thanks<br /><br />Jamesjfbhttps://www.blogger.com/profile/11281881673668731049noreply@blogger.comtag:blogger.com,1999:blog-4172950626830217643.post-40903194387314136492013-07-08T00:47:36.735-04:002013-07-08T00:47:36.735-04:00Right again -- this is a good example of how this...Right again -- this is a good example of how this topic gets pretty tricky if you want to plug all the gaps. (As I get time I'll post things I've run into... but time always seems to be scarce.)<br /><br />Quick version: Yes you have to think of any way in which a message can be misunderstood that can affect the length. That includes length implicit in message headers. One way to solve this is make all messages the same length so the problem can't happen, fragmenting if necessary. <br /><br />Another way is to put a CRC on the message header to detect header corruption (FlexRay does this; for a protocol that doesn't do this you could make the first byte of the payload a CRC on the header field). <br /><br />A third way is to have headers that have a high hamming distance between each other. One way to do this is, for example, to use the first few bits of the header as the actual header and the rest of the header bits as a CRC protecting those first few bits. The network protocol will just see this as a sparsely populated header space, but you'll know that it is hard for a single bit flip (or more perhaps) to accidentally change the header and therefore change the implicit length. <br /><br />The last way I've seen it done is with a high-hamming-distance set of synchronization bit patterns (I think this was Train Control Network), with the sync bit pattern determining which of a few message types are being used and thus implicitly the length.<br /><br />Phil Koopmanhttps://www.blogger.com/profile/11849599272360094243noreply@blogger.comtag:blogger.com,1999:blog-4172950626830217643.post-63188228549592184922013-07-06T13:53:29.632-04:002013-07-06T13:53:29.632-04:00Actually, I've been pondering this today and f...Actually, I've been pondering this today and framing seems to be real trouble...<br /><br />For instance Modbus, a single flipped start bit after a packet would shift to half of CRC + FF, the 'idle 3.5 characters' having received an additional character.<br /><br />If instead one used a high bit (address etc.) to indicate the first byte of a packet, and the CRC were directly after, two flips would get you checking the CRC at the wrong location as well.<br /><br />Do you have any pointers/references/etc. for how to avoid this problem? (Or have I missed something that makes it less of an issue?)<br /><br />Thanks<br /><br />James<br />jfbhttps://www.blogger.com/profile/11281881673668731049noreply@blogger.comtag:blogger.com,1999:blog-4172950626830217643.post-14134493041134007212013-07-06T07:12:48.822-04:002013-07-06T07:12:48.822-04:00James -- this is a great point! Glad you found it...James -- this is a great point! Glad you found it sooner rather than later.<br /><br />Cheers,<br />-- PhilPhil Koopmanhttps://www.blogger.com/profile/11849599272360094243noreply@blogger.comtag:blogger.com,1999:blog-4172950626830217643.post-47099809849160829082013-07-05T23:53:20.009-04:002013-07-05T23:53:20.009-04:00Hello,
Length field is a subtle one: if your prot...Hello,<br /><br />Length field is a subtle one: if your protocol has a 'command number' at the start and different commands have different lengths, one's effectively the other. Glad I realized this yesterday instead of next week when it'd have been too late...<br /><br />Thanks<br /><br />James<br />jfbhttps://www.blogger.com/profile/11281881673668731049noreply@blogger.com