Does the Arduino platform offer flash code (CRC) scanning?

Some of the new microcontroller models Microchip, PIC, Atmega, Attiny (now Microchip also the owner of the Atmel chips) were developed with the code scan. This helps prevent accidental changes to the code. In this way, the developer can offer greater reliability in the system.

AVR236: CRC check of Program Memory on tinyAVR and megaAVR devices with LPM instruction

This application note describes CRC (Cyclic Redundancy Check) theory and implementation of CRC to detect errors in program memory of the Atmel AVR microcontroller.

Many people think that the Arduino platform is an amateurish thing, but I think they are great cards. It would be great to be able to put the Arduino board in the nose of these people, to show that the Arduino works with the automatic coding scan. Atmel chips were more immune to electromagnetic interference than older PICs, so I also rely heavily on the Arduino.

Enjoy and download the new datasheet of Atmega328 (Used in Arduino Uno, Nano, Mini Pro etc) - Available from Microchip :wink:

Also visit the new Atmega328 page!

Thank you!

The Arduino does not currently do a code scan. There is nothing that would prevent it from doing so as an add-on, but there are a couple of issues:

  • You have to decide whether you're going to include the bootloader, keeping in mind that the sketch and the bootloader code can change independently. And that the upload procedure can't write EEPROM on most Arduinos.
  • Same issue WRT "empty" program memory. The last page of a program written to flash can contain somewhat random data, I think...
  • Most importantly, you have to have some idea what it is you're going to do if the CRC fails. Is "don't run at all" actually better than "run with a piece of corrupted memory"? How do you indicate the error to the user/owner, considering that there may not be any visible connection, and/or that doing anything to a visible connection may involve the damaged memory?
  • On top of that, corrupted flash memory is pretty rare. Short of the upload itself (which is already verified), you are much more likely to have developer-induced bugs than experience corruption of the flash memory.

IMNSHO, these "CRC the code" schemes are something dreamed up some management wog with a CS background, and not much practical experience. :frowning:

Agree with westfw - whole thing doesn't make sense. IMO the correct way to deal with misguided requests is to explain why they're a bad idea

Re #2 - More than just the last page will be full of data that isn't part of the current program - if you upload a sketch that fills the flash, then upload a much smaller one, and do so using the bootloader, everything after the end of the last page of the smaller one will be full of garbage (well, parts of the previous sketch - but garbage as far as the CRC check is concerned).

Also - if you're concerned that the flash could somehow corrupt itself, all bets are off, because the code that checks the CRC could be corrupted too!

Checking the CRC of the code has a place when using a custom bootloader where you get the code over some unreliable network (for example over the internet, or some wireless protocol) where the reset into the bootloader is initiated by the sketch (as opposed to the hardware reset line); in these cases, you probably want a failed flash to not jump to the bad application code, and instead wait for new firmware.