Leveraging the Nonvolatile Storage Services of MAXQ® Processors

introduction

Applications that require a microcontroller also often require some mechanism to preserve settings even when power is lost. For example, a radio that loses its previous station settings when the battery is changed will not be successful in today's market. Customers expect favorite channels, temperature presets, parameter preferences, and other persistent information to be preserved.

To meet customers' requirements for nonvolatile data storage, designers often use a serial EEPROM. These EEPROM devices are small, inexpensive, and have been in the market for a long time, making them very convenient for design engineers. However, in today's cost-sensitive market segments, adding an inexpensive EEPROM may put the design out of budget.

Many processors use flash memory for program code and static RAM for data information. Although it is attractive to take advantage of the unused portion of flash memory for nonvolatile data storage, the traditional Harvard architecture restricts this application. The MAXQ architecture is a Harvard architecture with separate code and data buses. However, the MAXQ devices contain hardware that implements a pseudo-von Neumann architecture, accessing code space as data space. This additional versatility, combined with the MAXQ's utility functions to perform erase and write services on the memory, provides a solution for a complete read-write nonvolatile memory subsystem.

Basic considerations about flash memory

Flash memory is an electrically erasable storage. It is also often referred to as "read-mostly". In short, although flash memory is writable, data is not updated very often, and most operations are read operations. Most flash memory devices are literally writable, but can only be erased as a whole block at a time. This makes those memory devices generally unsuitable for volatile storage, and only suitable for fixed data storage that never changes.

There are two types of flash memory: NAND flash and NOR flash. NAND flash is used in memory cards and USB flash drives. Generally, it takes several cycles to read data from a NAND device because the data is transferred serially according to the clock. This sequential operation makes NAND flash memory unsuitable for program code storage because the read time is too long. In contrast, NOR flash memory is similar to traditional byte-wide or word-wide storage. Reading NOR flash memory is like reading a ROM device: first send the device select and address command, wait for enough access time, and then read the data from the bus. NOR flash memory is used in MAXQ processors.

Flash memory for MAXQ processors

Flash memory cells used in MAXQ processors are reset to the "1" state when they are erased. Therefore, after erasure, each location in the memory cell will contain 0xFFFF. Programming a memory location changes some bits from the "1" state to the "0" state. In order to return the programmed bits to the "1" state, the entire cell must be erased.

The problem that must be faced by any electrically erasable memory device is endurance. Depending on the specific technology, a flash memory cell can tolerate as few as 1,000 erase cycles and as many as 1,000,000 erase cycles before it completely fails. Therefore, any application using flash memory for data storage must ensure that write cycles are evenly distributed throughout the array and that no single location is erased and programmed more times than another location.

Most flash memory devices allow unprogrammed bits in previously programmed locations to be changed from the "1" state to the "0" state. For example, on most devices, it is possible to program a location from 0xFFFE to 0x7FFE without any single bit changing from "0" to "1" during this programming process. However, the flash memory used in the MAXQ family of devices does not allow reprogramming of locations that have already been programmed, even if no change from "0" to "1" has occurred. Such a write operation will fail, leaving the data in the 0xFFFE state.

The reason for the restricted programming of MAXQ devices is as follows. The memory cells being programmed are initially used as code space, so care must be taken to prohibit any write operations to locations that have already been written. The 0xFFFF instruction indicates an invalid source code, which is unlikely to appear in a valid code location. Therefore, preventing write operations to locations that have already been programmed helps maintain the integrity of the code cells.

Design Solution Using the MAXQ2000

In this article, we focus on one MAXQ device: the MAXQ2000. This microprocessor has 64kB of program storage space, divided into 128 cells, each with 256 16-bit words. Two design options are presented below. The first option is suitable for information that is written once and does not change frequently during the life of the product, such as calibration data, version information, and feature parameters. The second option is for more general devices, where the design allows for data that changes frequently, such as usage information or detailed records.

Solution 1

Problem: Calibration data needs to be stored in the product. The product will always need to be recalibrated, so the calibration data must be stored in a rewritable memory space.

Solution: This is actually the simplest case imaginable. Two locations in the MAXQ2000 program memory space are reserved for storing calibration data, one at word address 0x7E00 and the other at 0x7F00. When the MAXQ2000 receives the command to save calibration data for the first time, it checks both locations and makes sure they are empty. The calibration data is saved to the first location.

When the MAXQ2000 receives the command to save calibration data a second time, it checks both locations again. If location 0 is already in use, it copies the calibration data to location 1 and then erases location 0.

When the MAXQ2000 receives a request to read calibration data (such as at power-up), it reads both locations to see which is in use. The location that has not been erased is used to configure the device to the calibration state.

The main advantage of this solution is simplicity. This approach is useful for applications that require configuration at power-up (or other configuration recovery situations). The read routine receives a word pointer and returns the contents of that address. The write routine receives a word pointer and attempts to write to that address. The erase routine erases both cells.

The disadvantage of this scheme is that the subroutines are extremely unintelligent. There is no way to determine whether the write operation succeeded. If the write operation fails, no action is taken to resolve the problem. This limitation is why this scheme only works for writes to known empty cells.

Solution 2

Problem: Non-volatile storage is used to track electricity usage and other data that changes frequently. Updates can range from a few times a week to a few times a day. Electricity meters are a good example of an application.

Solution: Even traditional EEPROMs need help in this case. The problem is that frequent updates and the inherent limited electrical erase life of erasable memory technology preclude the use of a single EEPROM with frequent write and erase operations. Suppose the application requires updates every hour. An EEPROM with a 10,000 write and erase cycle limit would only last for a year, far short of the 10-year life design goal required for the electricity meter application.

The solution to this problem is to implement "wear leveling." This means that writes are not repeated to a single location. Instead, writes are evenly distributed throughout the memory array.

Wear leveling is accepted and used in flash memory devices for this purpose. The algorithm is complex and difficult to understand. But for our purposes, a simple explanation of the mechanism will suffice.

In this design, data entries in the memory array are referenced not by address, but by data element number. The data element number is an arbitrary 8-bit value that corresponds to a data element. So in this scheme there can be a maximum of 255 data elements (data element 0 is reserved). Each data element contains: a two-byte header including the data element number and the length of the data element (Figure 1); a two-byte code indicating 1, 2, 3 or 4 16-bit words to leave enough remaining space for error management.


Figure 1. Data element header structure

When writing a data element, the write routine must know the data to be written, the length of the data element and the location where the data is to be written. It is easy to know at which address the data is written; whether it is a new data element or an update of an existing data element, it is written at the end of the storage array. The write command searches for the end of the array and then writes the new data element immediately after the last record. If there is not enough space in the current storage page to store a data element of a certain length, the page end marker appears and a new page is opened. Figure 2 shows the structure of such a typical data page.

In this data page, data element 1 is written first and updated. Then data element 4 is written, but never updated. Then data element 3 is updated 7 times in total. Finally, data element 2 is written and never updated.

The presence of the end-of-page marker indicates that a write operation was performed, but the data element was too long to fit into the current page. A new page is opened to fill the data element. An empty element is allocated at the end of the entire data structure, where a data element header should be.


Figure 2. Typical data page

Note that this scheme does not address the issue of duplicate records. Duplicate records are not a problem. In fact, both the read and write routines completely ignore duplicate records. When writing, new records are written to the end of the array regardless of whether a record with the same number exists. When reading, only the last (and therefore most recent) record matching the requested record number is read.

Reading data elements from the array is more complex than writing. The read function receives the data element number and the address where the data element should be written. When executing this command, the read operation searches from the very beginning of the array. When it finds a record matching the requested data element, it saves this address and continues searching. When it finds another matching record, the read command replaces the saved address with the new address. When the end of the array is reached, the saved address will be the most recently written record matching the requested record. When a read operation is performed, this data is copied to the cache.

Although the described master read mechanism for saving and retrieving records from the storage array is feasible, there is still a problem: there is no mechanism to reuse the space occupied by obsolete records (there is also no mechanism to delete records. However, since this solution is developed for embedded applications, this may not be a serious problem.). If some space is not recovered, the previously allocated space will soon be exhausted. Since flash memory can only be erased one entire page at a time, recovering space means erasing the entire page. Another more serious problem is that flash memory pages cannot be erased randomly, and there is a risk of deleting useful information. The only option is to copy the useful information to a new page before deleting the entire old page.

There are three steps to recover space from obsolete records. First, open the new page and copy the latest version of each data element to the new page. Second, erase the old page. Third, mark the new page so that the read command can find the new page.

The first step is more complicated and requires more detailed examination. The simplest way to accomplish this step can be divided into two sub-steps: first, use a RAM to store the record number and address of the most recent record in the array; second, copy the most recent record from the RAM array to the new flash page one by one. This process is the fastest and relatively simple.

The problem with using these two sub-steps is that the MAXQ2000 only has 1k words of RAM space. The above solution limits the amount of data that can be stored in RAM for buffering. This is obviously unacceptable.

The solution to this dilemma is very time-consuming, but it is feasible no matter how large the storage array becomes (within reason). Instead of setting up pointers in RAM, a separate operation is performed for each entry in the source array. Therefore, the algorithm can be simplified to:

1. Read an element from the source array.
2. Search for this data unit in the target array. If found, it means that this data unit has been written. Increase the source pointer and return to step 1.
3. Searches the source array for the most recent record for this data element.
4. Write the most recent record of this data unit into the target array.
5. The source pointer is incremented and returns to step 1.

Finally, in the target array, each data element has an exact entry corresponding to it. The filled page is shown in Figure 3. In this way, the source page can be safely erased and the page header can be written to the target array.


Figure 3. After space recovery, the data page in Figure 2 will appear like this.

This process is very safe for data storage. However, there is another risk when using flash devices: power failure during a write or erase operation. If a power failure occurs, it is possible that one or more pages will be destroyed (such as a write operation) or the page will not be completely erased (such as an erase operation). Our compact operation is inherently safe. The following scenarios can be considered:

• If power is lost during a fill operation, the source page remains intact. When power is restored, it is easy to identify the newly written page (they have no page header) and erase it, and restart the fill operation.
• If power is lost while old pages are being erased, they may contain invalid headers. These pages can be erased and the headers added to the new pages.
• If power is lost while the page header is being written to a new page, the data is still intact and the page header update operation can be restarted again.

In short, these unexpected incidents will not cause array data to be corrupted and unrecoverable.

Improvement of Solution 2

The storage subsystem presented here has no error detection mechanism. Some bits (here 6 bits) in the data element identifier are not used. A CRC can be calculated based on the data element using the CRC6 algorithm (x6 + x + 1) to ensure that no read or write errors have occurred. Although this is not a particularly powerful algorithm (it will miss 1/64 of multi-bit errors), it can detect most of the errors that may occur.

Another limitation of this method on the system is that the read time is very long. Each read operation requires reading all records in the array to find the most recent record. There are three methods that can be used to shorten the read time:

1. Leave a null byte for the forward pointer in the data unit. When the data is updated, assign a new entry address to the forward pointer. In this way, the data table can be moved in a linked list manner.
2. Moves the table backwards. This stops the search at the first occurrence of the requested signal.
3. If the number of cells is small, a RAM array can be created at startup, containing the cell IDs and pointers. Subsequent reads will be fast. Only the RAM array needs to be read to determine where to get the data cell.

in conclusion

Nonvolatile data storage is a problem that every design engineer must face sooner or later. Using the flexible flash memory of the MAXQ processor, there is no need to resort to serial storage to save configuration data.