The requirement for small-to-medium density data storage crops up in many applications where designers need non-volatile storage of variables which change infrequently, such as calibration parameters, configuration settings, or data and event logging. The most common solution to this problem is to use an EEPROM, linked via a serial interface to the microcontroller. This solution is compact, robust, flexible, easy to implement, and inexpensive.

Some microcontrollers, of course, offer on-chip data EEPROM, which offers an advantage in speed (parallel access to the memory), and frees up two or three I/O pins. However, the increased number of process and test steps required to implement on-chip EEPROM impacts the fi nal price of the micro, and gives the user limited flexibility in available memory sizes. Even if a micro is available with exactly the right feature set for the current application, when the designer needs to move up or down the range, the options for retaining on-chip EEPROM are restricted.

Emulating EEPROM Functionality
An alternative solution uses the microcontroller’s FLASH memory to emulate the data storage behavior of EEPROM. This technique requires a slightly more complex software driver, but provides flexibility in memory size, and is effectively free of charge, assuming there is on-chip flash to spare. Until recently, adoption of this approach has been limited, as many microcontrollers suffer fundamental weaknesses in architecture, or FLASH sector sizes, data retention, writeerase cycles, page banking systems, power supply restrictions during programming, or the need to run from RAM when writing to flash, which can threaten the security of the application in the event of power loss. Individually, none of the weaknesses poses an insurmountable problem, but collectively, they add to the project’s time-to-market, practicality and final cost. Dedicated on-chip hardware is not the answer, as this approach continues to restrict the user to a limited number of options within a given controller family.

To find a solution, we need to look at the application differences between off-chip serial EEPROM and onchip FLASH memory, and at the architectural and functional features provided by the latest generation of microcontrollers. EEPROM is designed for data storage, supporting random access byte addressing, with erase and write functions integrated into one step for simplicity. Speed is not usually an issue, but page or line modes are supported for writing typically 16 or 32bytes at once for saving system configuration at power down. Robustness is very important, with perhaps one hundred thousand to one million erase-write cycles, and tens of years of data storage.

On-chip FLASH, on the other hand, is optimized for high-performance program execution. This requires not only fast random access, but even more importantly, an ultra-wide data bus and burst mode facilities such as a memory acceleration. These things are not usually so important when choosing an EEPROM. There can be benefi ts; for high speed reprogramming, FLASH arrays support page and mass erase, bringing some advantages when it comes to data storage.

Sacrifices
However, to deliver high performance on-chip FLASH at low-cost, some nice-to-have features must be sacrificed. As released code in the fi eld doesn’t normally need to be updated quite as often as non-volatile data, the number of erase-write cycles is typically an order of magnitude lower than an external EEPROM. Another important difference is that once the data has been received and the write cycle triggered, an external EEPROM takes care of completing the process, assuming its power supply remains stable, whereas on-chip FLASH requires continuous support from the CPU.

Overcoming Differences
A satisfactory solution to the problem must compensate for the philosophical differences between memories optimized for code and data. This requires a combination of modern microcontroller design with a practical software driver. One technique adds a tag, or virtual address, when storing each byte of data, and uses multiple FLASH sectors to extend the effective number of erase-write cycles. As a side effect, the amount of memory needed to store the application data increases, but this is offset by both the lower cost-per-bit of FLASH, and the small sector sizes of modern microcontrollers. A very simple implementation uses two FLASH memory pages, but this can easily be extended if required.

One page is gradually filled on a byte-by-byte basis, while the second page is readied to take over when the first page is full. To track the process, each page has a header field which includes the current status, indicating if the page is empty, currently being filled, or full. When the application needs to store variables in the emulated EEPROM, each variable, along with its virtual address, is written to the next free location in the current page. This also applies when the variable is re-written – the old value is not overwritten, but the new value is written to the next available location.

If the application needs to read the variable, the current page is searched for the most recent entry. When the current page is full, a “garbage collection” process is run, and the most recent value of each variable is copied to the new page. The old page can then be erased. With the conventional approach of storing each variable in a fixed address, the erase-write capacity of the entire device is defined by the most frequently changing variable.

The tagging approach spreads the load equally across the FLASH pages, raising the effective endurance ceiling. For applications where a small number of the variables change most regularly, it is possible to achieve an order of magnitude improvement, bringing the performance up to the levels expected of an external EEPROM.

Historically, it was not possible to execute code from one bank of FLASH while programming the same bank. Where system cost is an issue, multiple banks of FLASH are not an option, therefore in older microcontrollers, it was necessary to execute from RAM when reprogramming the FLASH. Today’s micros have no notion of FLASH banks, and instead embed support for writing and reading in parallel to and from one uniform FLASH array.

Power supply management is very important. A single supply voltage is preferable to avoid having to switch and monitor programming voltages during run time. New micros must be capable of reprogramming their FLASH arrays at either extreme of the power supply range, which some older low voltage designs could not achieve.

Example of FLASH-based EEPROM Emulation with Wear-Levelling (16-bit data)

A flexible, accurate, Auxiliary Voltage Detector is also necessary to alert the CPU when power down is imminent, giving it enough time to save critical data before shutting down.
In the event of power loss during programming, with FLASH just as with EEPROM, it is possible for data or the page status to be corrupted. To recover from this, the page status headers should be checked immediately after power up. At any time, only one page should be “valid”, in which case the software can choose to fall back to these values if there is any suspicion that the other page could have been corrupted. If neither or both pages are “valid”, then something has been corrupted; both pages should be erased and the application parameters returned to default settings. Additional status levels and software locking and handshaking can be introduced if the application demands even higher levels of security.

Conclusion
EEPROM emulation has always been possible, but is only with the availability of new generation microcontrollers, like the STM32, that the solution becomes robust and problem free. By coupling the right micro family with a suitable software driver, the design engineer can implement effective and flexible EEPROM emulation, reducing component count and system cost.
Source: Technology First.