| ??? 11/02/06 13:40 Modified: 11/02/06 13:43 Read: times |
#127256 - \"legitimate\" uses of checksum Responding to: ???'s previous message |
Erik Malund said:
The best example I have seen of the futility in transferring what used to be to what is is that I once saw a mask programmed chip with a code memory checksum check. Well, who told you that maskROM cannot get wrong? This might be a perfectly valid manufacturing or even runtime test! Until you ultimately know the mechanisms and rates of failure of the memory/transport media used, you can't simply discard any kind of test as irrelevant - yes, even the plain' ol' checksum! Erik Malund said:
want to check a section which is likely to be corrupted e.g. when ISP reprogramming goes wrong. That is the one relevant use I know of. With chips with a readback capability, however, I prefer a compare of each and every byte. Readback is good only when programming. Checksumming is still valid for example to find out if the non-safe memory has been corrupted in some way later, when in usage. Erik Malund said:
HOWEVER, the likelyhood of the checksum checking working (not corrupted) and something else being corrupted is infinitessimally small. Again, you can state this only with detailed knowledge of failure mechanisms. Even if you'd assume the most simple failure mechanism: a small and uniform (across the code memory) probability of single bit flopped permanently; as the CRC calculation is likely to reside only in a small portion of the code memory, it is quite likely it remains uncorrupted and spots this error (most CRCs have 100% coverage of a single bit error); plus the bonus of being corrupted so that it won't give the proper result (which i IMHO quite likely too, but I won't make predictions on this). However, this indeed might be not the typical failure mechanism for most modern flash-based microcontrollers; yet you cannot make the above statement generally without having deeper knowledge on them (which I don't have, I admit). Jan Waclawek |
