Almost all applications in embedded systems need to store some data in non-volatile memory areas to have it available after power loss. A lot of those systems until now have used external serial EEPROM circuits for that purpose.
Nowadays, microcontroller suppliers offer their chips with integrated data FLASH areas that can replace the additional EEPROM. This data FLASH is a significant advantage in terms of test effort and cost reduction.
But the change from an EEPROM to an internal data FLASH is not as easy as it seems. In this article, I will give an overview of the main differences between an EEPROM and a data FLASH and what an embedded software system has to do to manage data in an internal data FLASH.
I am interested in safety items, so why should I read this?
I know some application notes from hardware vendors about EEPROM emulation, but all of them are specific for their design, and there is no general overview.
Especially the safety aspect is not covered by those publications. I think storing data and ensuring data consistency is one of the top functional items in all embedded systems. You don't think so? Ok, so ask the functional safety manager of your trust, how to deal with data loss of safety-critical data stored in non-volatile memory and the item will be on the top five of your most critical questions list.
This article is a try to reflect the technical aspects of migration from EEPROM to Data FLASH, including the safety aspects.
EEPROM vs. Data FLASH? Isn't that the same?
Indeed the technological base of EEPROM and FLASH is the same. Moreover, we can say that hardware vendors are deriving the FLASH technology out of EEPROM technology. Both techniques are electrically programmable and erasable read-only memories.
But there is one crucial difference: We use the term "EEPROM" for devices that are erasable on a per-byte or per "programming word" basis. Whereas we use the name "FLASH" for devices which only support erase capabilities in their entirety or on a sector base (mostly > 1k). Well, this main difference we are talking about in this article. This article uses the terms in "EEPROM" and "FLASH" in this intention.
Note: Unfortunately, some chip vendors call their byte erasable products "FLASH" just because of marketing reasons. The term "FLASH" gets popular as a synonym for fast writable memory.
Additional to the erasing behavior, there is another technological difference, that influences the data management in EEPROM and data FLASH. This difference is the timing of writing and erasing.
The following table gives an overview:
|Feature / Characteristic||EEPROM||FLASH|
|byte write time||1ms to 10ms||< 100µs|
|erase time (entirely)||5ms to 50ms||from seconds up to minutes|
|erase / programming cycles||from ~100k up to >1 million||from < 10k up to < 100k|
Finally, when using an internal data FLASH of a microcontroller system, there is one more slightly different in comparison to an external EEPROM:
An external EEPROM will finish a started write command as long as the device is powered, even if the microcontroller is already in reset state or clock failed.
An internal data FLASH of a microcontroller depends on the clock and the reset of the micro and will suspend write or program cycles immediately if one of the signals fails. Furthermore, some microcontrollers will stop parts of the internal peripheral (e.g., timer) during FLASH erase cycles.
This internal behavior is one point that has to be taken into account, for example, in shutdown and emergency storage situations.
Sounds interesting, but what are the consequences?
For non-volatile data management, these differences have a considerable impact. To get a feeling of the effects, we will construct a typical requirements scenario for non-volatile data management. After that, we have a look at possible solutions on how to handle this scenario using an EEPROM and an internal data FLASH.
Let us construct the following use case:
We want to store 3 data items in a non-volatile memory area: NVData0, NVData1, and NVData2. The length of the data items shall be 1 byte for NVData0, 2 bytes for NVData1 and 4 bytes for NVData3.
We know that at least one data item is updated periodically.
We are interested in functional safety, so let's postulate that all of our 3 data items have a safety impact in case of data loss.
The EEPROM Approach
Let's start with a look at how non-volatile data management usually works using an EEPROM device for our scenario.
When locating data in EEPROM memories, on the first look, these memories behave nearly like standard RAM. For now, we ignore the timing and internal operation behavior. So we assign a specific memory address to each memory item. In consequence, we can set up a memory map for our three data items to be stored in the EEPROM.
Ok, we found a place for our data items. But we are still not satisfied, because we have to prevent data loss and data corruption.
I am starting with detecting data corruption. A popular solution to that challenge is to add a CRC checksum to the data items. The length and algorithm parameters of the CRC strongly depends on the length of our data items we want to check, and the necessary diagnostic coverage. In our case, a CRC8 is sufficient.
In this state, one could say, from a safety point of view, everything is fine. We detect damaged data, go to the safe-state, and that's it. Well, we know that we update the data cyclically. Therefore, data damage is possible in case of sudden power loss.
This state is an example that safety measures do not automatically increase the quality of a system and vice versa! Unfortunately, this is a far-spread wrong assumption.
What we need is a mechanism to prevent data loss while keeping the availability as pleasant as possible. The simplest solution is to mirror our data items, which means we have to store the data items twice in our EEPROM. This simple algorithm means, when updating a data item, we first write the data at the primary location, and in a second step, we write the data at the mirror location. If a power loss occurs during the writing process, there is always a valid data set. Either at the primary location or the mirror location.
We can add additional diagnostic coverage by dividing up the EEPROM address space into two areas for primary and mirror data. This separation helps us to prevent that the mirror data gets corrupted together with the original data due to EEPROM hardware errors affecting neighbor memory cells.
The following picture shows the resulting EEPROM memory map:
This is a fix memory structure, which is easy to handle by memory management. The translation from data item to address is normally done in a layer called EEPROM Abstraction (EA). An example of a definition of such a layer can be found in AUTOSAR standard AUTOSAR_SWS_EEPROMAbstraction
The Data FLASH Approach
When using a data FLASH for the same scenario, two things fundamentally change:
It is not possible to overwrite data in a fixed address without erasing a big area of memory.
The maximum number of programming cycles for a single cell decreases dramatically (approximately by factor 10).
This leads to the common approach for saving data in an internal data flash:
The Flash EEPROM Emulation (FEE)
There are a lot of algorithms for emulating EEPROM in FLASH. The following is just one of them. The key challenges are the same for all of the possible algorithms. Dealing with the characteristics of a Data FLASH memory, the following techniques are usually taken.
The complete FLASH memory area is divided into at least two blocks. One of these blocks is the so-called active block. This block keeps the current saved data. The other block is the passive block. This block is empty.
Each data item to be stored has a fixed ID and a fixed length. This is a piece of constant information and fixed at compile time and therefore stored in program memory. Also, the start addresses of the data FLASH blocks and the length of the FLASH blocks is fixed at compile time and stored in program memory.
Data saved to the active block is written just one data item behind the other. For that, it is necessary to save also the information, where the latest data of a special data item has been written. This management information can be seen as a kind of simple data management system.
Keep data and management information separated. Data is written from the start of the active block to the end; on the other side, management information is written from the end of the active block to the start. Additionally, there must be some header information at the very beginning of each block, which marks the block as active or passive.
When the active block is full, which means data and management information meet somewhere in the middle of the active block, the latest data of each stored data item is copied from the active to the passive block. Afterward, the passive block becomes the active block, and the formerly active block is erased and becomes the passive block.
At start-up, the FEE driver first checks for the active block by reading the header information of the blocks. Then it checks for the latest entry in the active block by checking management information beginning at the block end until it finds an empty entry (erased flash cell). This marks the address for the next management info. The latest management information at the same time delivers the address and the ID of the latest data written to the flash. With that information, the FEE driver can restore the next address for data to be written to the FLASH. Data management is now initialized, and data can be read and written from/to the data FLASH again.
The following picture shows a typical memory mapping of an active FLASH block for our scenario:
Safety Aspects of FEE
Detection of corrupted data: As for the EEPROM approach for the FEE also a CRC may be used to detect corrupted data with the same considerations as already mentioned for EEPROM.
Prevention of data loss: It is also possible to store the data items twice in order to prevent data loss as already mentioned for the EEPROM approach. But it is not really necessary! As all new data is just written to a new flash address, all "old" data are still available in the memory. This way, there is always a valid copy of the data item available in the FLASH. Only the very first data entry should be written twice, as at that point of time there is no copy of the data item available. This can be handled by FEE driver.
Prevention of loss of management information: For management information, the same considerations are valid as for data items. This means that management information also should be protected against corruption by a CRC. Additionally, the management information can be stored twice (mirrored) to prevent loss of information. I would not suggest using the available copy of the management information of an older data copy of the same data item. Because in this case, you might use the older copy despite the availability of a correct data item just because of the corruption of the management info.
Conclusion and Consequences
Although EEPROM and FLASH memory is very similar to memory technologies, storing data to them requires quite different data management approaches. Especially the change from a fixed memory mapping in the EEPROM to a dynamic mapping with a simple data management in a FLASH makes huge differences. Following consequences should, therefore, be considered when migrating from an EEPROM to a data FLASH.
The size of the data memory must be adapted: Storing data in a FLASH memory requires much more space than in an EEPROM. This is first due to the fact that the management information has to be also stored in FLASH. Second aspect influencing memory size is the low number of programming cycles of the FLASH memory. Depending on the size of data to be stored and the store frequency FLASH memory should be 4 to 10 times bigger than an EEPROM.
Split up big data items: As a direct consequence of point 1.) big data items stored in EEPROM should be split up into smaller parts when migrating to FLASH. Big, frequently written data items would lead to a more frequent change between active and passive FLASH blocks because the blocks would be filled faster. Storing smaller blocks could prevent this.
Respect the run time for a block change: The driver must respect the run time for a block change from active to the passive FLASH block. Depending on the number of data items to be copied from one FLASH block to another, the driver will be blocked for a longer time for accepting storage commands from an application. A FEE driver should consider this by, e.g., bigger command buffer sizes in comparison to an EEPROM driver.
No data mirrors necessary: As there is always a valid copy available for the stored data items, there is no necessity of mirrored data. This eases handling of data corruption and prevention of data loss when using FLASH.
As we can see the migration from an EEPROM to a data FLASH requires a lot of work and care and doing this fast and easy is indeed a fairy tale. Hopefully, I have been able to make clear the main differences between the two memory technologies and the resulting consequences for the application.