Error Detection/Correction Code

I am currently working on a project to analyze the effects of cosmic ray radiation on microcontrollers. I have designed and fabricated a PCB to analyze hard errors; however, I am having trouble on the soft error aspect. Does anyone know of any good references for writing a memory checking code for flash/EEPROM/SRAM? Right now I have implemented a CRC check of flash memory, but I'm not sure that this is adequate. Additionally, I would also like to check EEPROM and SRAM. Thanks in advance!

1 Like

no reference, but you might create something that does do lets say 10.000 re-writes of the entire memory.
Some fast filling and some near random filling (butterfly test),
i think for a best result you write something like below each time over the same memory field

10101010
01010101
11110000
00001111
11111111

you might read the value before write (check if its correct) and do an OR function for the next write.
Note it takes a lot of time (or much radiation) to see some efffects.
Besides depending on the micro controller, the inner working the stack, the logic testing might be harder to do.
You need some code to do different types of logical unit testing (math / memory operations).
And be sure to check if the device is still functioning (I/O ports) AD/DA converters.
Do clock speed measurements, if the board contains other electrical units Condensators, transistors, elco's, diodes / zenerdiodes they could be affected too, and cause problems for the micro processor.

.. assuming your building something space related, it might be an idea also to check for shielding.
once you know what shield type is enough, to keep if safe for humans, you less depend on microcontroller testing.

Thanks for the input. This may be a dumb question, but how do I write (and read, for that matter) these binary values to the memory from the arduino IDE?

For the SRAM and EEPROM, you write a couple of loops that run during void setup only:
For EEPROM, use the EEPROM library
http://arduino.cc/playground/Code/EEPROMWriteAnything
For SRAM, you could define an array of say 1000 bytes, leaving 1000 bytes for you sketch variables & whatnot.
byte arrayTest[1000];
for (int SRAMaddress = 0; SRAMaddress <499; SRAMaddress = SRAM address +1){
arrayTest[SRAMaddress] = 0x55;
arrayTest [SRAMaddress+1] = 0xAA;
}
Not sure how you add 16K or whatever of similar data that gets programmed into FLASH with the sketch, or how you read it back.
I guess PROGMEM would be used somehow.
http://www.arduino.cc/playground/Main/PROGMEM
(be sure to scroll down, the page format looks a little funny, like the left hand menu gets in the way of the text)

If you are just checking the ability to write and read back from the EEPROM for example, you could use a [7,4] hamming code. Encode a string of 4 bit data blocks, store them to the EEPROM, read back, check the the huffman syndrome, and repeat. You would be able to detect two errors out of the 7 bits. You could throw in a parity check to use up the eighth bit aswell.

A similar thing would be possible with the SRAM.

With the program memory, you could write your code to occupy the bootloader section, and then it would be possible to access the remaining 30k of program memory (assuming an atmega328), or the other 254k(assuming an atmega2560). Then do a similar sort of check. Any byte which gets corrupted by <=25% would be detectable.

Hamming SEC codes are used by computers to detect and correct errors in bytes being read from the RAM. I'm happy to explain how they work if you want me to.

Thanks for the input! Crossroads, I've been working with your idea; however, I ran into a small problem (probably a simple fix!). Once I declare my array and SRAMaddress variable in the setup loop, I cant refer to these in the loop of the program without getting a "not declared in this scope" error. So the question is, how can I refer back to these items (which are initialized in the setup loop) during the main loop program?

Thanks again!!!

Ah, I think I've fixed it. I simply moved the definitions outside of the setup loop and called them in the setup. Is this a valid work around, or is there a better solution?