Using Flash Memory in Embedded
Applications
By Olaf Pfeiffer and Andy Ayre
[ Introduction | ISP vs IAP | Self-Recovery | Storing Variables | Flash Life-Time | Summary ]
Self-Recovery
For any system using Flash memory, the worst-case scenario includes a system failure, crash or power outage, while the Flash is being erased or re-programmed.
For some applications, a recovery via ISP might be acceptable. A service technician capable of doing the recovery manually might be at hand. However, it's easy to imagine that in truly remote systems (for example marine buoys), a more sophisticated self-recovery mechanism, not involving any person, is more desirable.
As an example, let's assume we have a network of buoys covering an ocean and collecting data. Each buoy can send and receive data via radio. After a year, the project team working on the data realizes that they can optimize their research with a few modifications to the code executed in the controllers in the buoys.
When uploading new code, the system should be stable enough to recover by itself, even if the system has a reset (or power failure) just right after erasing the Flash memory. Sending a maintenance crew to the buoy might take weeks and cost a significant amount of money.
To
ensure the recovery, it's vital to any application that the code starting at the reset
vector (starting at location 0) never gets erased or re-programmed. Furthermore, all the
code essential to the application must also be in code areas that never get erased. As a
minimum, this must include all the code handling the IAP part of the program. In our case,
that also includes all the radio communication routines.
In addition, routines are needed that can detect and decide if the code present in the re-programmable part of the application actually contains valid code. A jump or call to these program areas should surely only be executed after ensuring that real code is at the expected location.
One way to implement this is using checksums. If each code segment in an area that can be modified / re-programmed by the application has a predefined checksum (which can be achieved by adding fill-bytes that ensure a certain checksum), then the code testing routine only needs to calculate and match the checksum to decide if a piece of code is valid or not. Depending on the level of security needed, several checksums can be implemented.
For our example with the buoys, the entire re-programming procedure could work as follows: The controller receives the radio command to erase the Flash memory with the data collection routines. It does execute the command, but never touches the reset sector. It now receives the new code via radio and programs it into the Flash memory.
In the worst case, the system has a malfunction right now, before the programming is complete. Let's assume the system restarts after a while: the code in the reset sector is still present and executes. It recognizes a checksum failure in the code sector handling the data collection. Using the radio link it transmits this status and waits to receive new re-programming commands.
[ Introduction
| ISP vs IAP | Self-Recovery | Storing Variables | Flash Life-Time | Summary ]
Copyright (c) 2000 by Olaf Pfeiffer and Andy Ayre
ESAcademy, 2000
All materials
provided 'as is'
see Disclaimer