Below is my assessment and solution to the time limit on FLASH memory data storage. This becomes a problem when used with secure bootloaders, where the bootloader FLASH can never be updated by the customer. I would like to know if anyone else is willing to share any thoughts on a better way to do this.
I am implementing an AES bootloader which will have the bootloader FLASH locked. The On-Chip Debug, JTAG and Serial program download fuse bits will all be set to disabled. In addition, the Memory Lock Bits (LB2:1) and Bootloader Memory Lock Bits (BLB12:11) will be set to disable bootloader programming access. This will prevent further programming and verification in Parallel and Serial Programming mode and prevent the application section from using LPM or SPM on the bootloader FLASH.
I almost forgot the AVR FLASH has a time limit on how long it will retain its data. Most FLASH devices will guarantee 10 years, but I cannot find this specification for the AT90CAN128 FLASH. Since the bootloader has the AES encryption keys, I cannot send a copy of the bootloader out to the customer for reprogramming, even if they have the AVR parallel programmer hardware.
This configuration of bootloader security combined with the FALSH data shelf life appears to make the AVR chip a kind of ticking self destruct time bomb, even if it does take more than 10 years to destruct.
The solution I came up with is a program that lives in the bootloader space and copies the bootloader FLASH back onto itself. It is a maintenance program that would probably only need to be run once every 9 years or so. The maintenance program can be selected and run when the external ISP computer is connected through the bootloader code. The maintenance program does have one problem. If anything serious goes wrong, like a power failure during the FLASH maintenance rewrite, it will corrupt/disable the AVR chip and require repair (factory full chip erase and parallel reloading). So, the maintenance program should only be run as often as needed to help mitigate this risk.
Since the maintenance program is self contained in the bootloader, running it will not expose the AES keys or other bootloader programing to the outside world. Its job is to simply rewrite the bootloader FLASH program (including itself), so that the 10 or whatever year data shelf limit gets a fresh start with another new 10 or whatever years.
In order to ensure the ability to recover from a failed attempt to load new application FLASH firmware, my AVR reset vector fuse is set for the bootloader. The bootloader software decides if the application or bootloader is going to be run. There is a physical emergency recovery jumper to force the bootloader to run in case the application program is toast. When the application program is working, it can also start the bootloader if desired.
I recently asked ATMEL support about the FLASH data shelf life specification. I also asked if I had to erase the page or if I could skip the erase and just rewrite it to begin another 10 or whatever year data shelf life cycle. Obviously, if the page must be erased, then maintenance programs must exist in two different bootloader pages to avoid erasing the maintenance program code while it is running. If anyone is interested, I will post the ATMEL support answer after I get the reply.
Any discussion or better ideas, etc.?