From time to time I do include a RAM test in code. This will come about because the customer has project requirements that are based upon the relic of history. Rather than talk the customer out of the RAM test it is often just as convenient to just go ahead and do it. I add the RAM test as part of the assembler language start-up code for C. If you are interested I can send you an assembler source for a ram test that checks the XRAM space. I do not ever test the regular 128/256 byte data space for the reasons cited by Kai. For the code just send me an email.

For code integrity check, it can be done by checksum. If I use a checksum I use a modulo 2^^16 summation of all the bytes. I prefer however to use another scheme that is more robust in that it is sensitive to data ordering changes that uses a simple XOR CRC scheme. Either way the use of a code validation scheme is most useful for providing an indication that the correct version of firmware is installed in a product as opposed to finding the program actually bad. I don't think that I have actually ever seen a code integriy failure reported in a product that I implemented on a microcontroller with on-board FLASH. Of course there have been instances of the Checksum/XOR CRC catching cases of operator mistakes in programming by taking the chips out of the socket too soon or cutting power before programming was complete. So maybe that is a justification for some code integrity checking. At least it "may" report an issue at final test of the product if in the small chance that the buggered FLASH image even runs.

Michael Karas