AN2040 APPLICATION NOTE EEPROM Emulation and Data Record Storage Using the uPSD32xx Generally, EEPROM devices are used to store and retain data in the event of power failure. The data may be retrieved whenever required, and can be repeatedly updated (the device ratings usually specify an up- per figure between 100 thousand and 10 million Write/Erase cycles). One of the main differences, from the user point of view, between EEPROM and a uPSD device (which includes an extremely large Flash memory array) is the minimum granularity for erasing data. Typically, EEPROM allows the user to modify single byte locations: that is, data stored at a specific address can be updated individually. In contrast, the uPSD Flash memory provides random-access non-volatile data stor- age, a byte at a time, but can only be erased a sector at a time. However, Flash memory in general, and uPSD in particular, offers so many other advantages to the de- signer that it is often better to emulate the EEPROM in Flash memory, rather than to have a specific EE- PROM device. Emulation is achieved by employing two Boot Block sectors in the uPSD device: one that starts off erased, and offers byte-at-a-time programmability, and the other ready to take over when the first one needs to be garbage collected. The byte-at-a-time programmability uses a linked-list data storage algorithm to update stored data until the sector is full, at which time the valid data is swapped to a different sector and the orig- inal sector is erased. The EEPROM emulation code (which is listed in the appendices of this document) swaps data between the sectors as they become filled, in a manner that is transparent to the user. The EEPROM emulation driver meets the following requirements: ■ Minimum use of SRAM ■ Simple and easily updateable code model ■ User API consisting of initial format, read record, update record ■ Clean-up and internal data management transparent to the user ■ Background sector erase ■ Code in main Flash memory, database in boot Flash memory ■ At least two boot Flash memory sectors to be used, more if possible for wear leveling ■ No timers, interrupts or RTOS The EEPROM size to be emulated is flexible, within the limits and constraints of the sector size, and allows for a maximum EEPROM size of 8KBytes in the current implementation, which is the sector size that is defined by the uPSD32xx architecture. The header and source file, written in C on the Keil IDE for uPSD, are held in eeprom.h and eeprom.c (respectively). These can be downloaded with the C code, and use sectors 0 and 1 of the secondary (boot) flash to emulate EEPROM data storage. A sample demonstration program is also supplied to demonstrate and test the EEPROM Emulation using the DK3200 board. This application note describes the EEPROM Emulation driver, and the small demonstration program writ- ten for the DK3200 hardware demonstration kit (which incorporates a uPSD3234A device). September 2004 1/25 AN2040 - APPLICATION NOTE TABLE OF CONTENTS OPERATION . 3 User API . 3 EEPROM_Format . 3 Update_Record . 3 Update_Record (BYTE id, BYTE *buf) . .4 Read_Record . 4 Read_Record (WORD id, BYTE *buffer). 4 Eeprom_Init . 4 Data Structures and Error Recovery . 4 Figure 1. Data Storage Map . 5 Interrupted Sector Erase . 6 Interrupted Sector Swap . 6 Figure 2. Sector Swap Flowchart . 7 Table 1. Sector Status Byte Matrix . 8 Figure 3. Data Integrity Check Flowchart . .9 Lower Level Functions . 9 Write_Record (WORD id, BYTE *buffer) . 9 Boot_Flash_Write (WORD address, BYTE data_byte) . 9 Read_Record_Data_Structure (WORD id_number, BYTE *buffer) . 10 Boot_Flash_Read (WORD address) . 10 Eeprom_Sector_Erase (BYTE sector). 10 Eeprom_Sector_Erase_Start (BYTE sector) . 10 Eeprom_Sector_Erase_Suspend (BYTE sector) . 10 Eeprom_Sector_Erase_Resume (BYTE sector) . 10 Eeprom_Sector_Erase_Status (BYTE sector) . 10 Find_Next_Address (void) . 10 Find_Active_Sector (BYTE io). 10 Eeprom_Sector_Swap (BYTE inn, BYTE *buf) . 10 E_andF_Sector (BYTE sector, WORD max_rec) . 10 Get_Sector_Status (BYTE sector). 10 EEPROM Emulation Demonstration on DK3200. 11 Figure 4. Startup Screen. 12 Figure 5. Merging of MCU Firmware with PSD Screen . 13 APPENDIX A.UPDATES ENDURANCE COMPUTATION . 14 Parameters and Assumptions . .14 APPENDIX B.EEPROM EMULATION Demo code . 16 Changes to be Made at Compile Time. 16 APPENDIX C.DK3200 EEPROM DEMONSTRATION PROGRAM . 20 REVISION HISTORY. 24 Table 2. Document Revision History . 24 2/25 AN2040 - APPLICATION NOTE OPERATION This section describes the key features, functions and basic operation of the driver code. The algorithm used, in the supplied driver code, makes use of the robustness of the Flash memory device. By organizing the data and record entry in the particular structure that it does, provides for maximum data integrity as well as allowing for virtually unlimited updating of the data (APPENDIX A.). The EEPROM Emulation code requires input from the user, for it to determine the allocation and formatting of the memory sectors. Required parameters are explained in the User API. (The sample demonstration program, for example, uses 1 record of 128 bytes). Based on this input, the driver code reserves enough memory immediately after the sector header to hold one instance of each data record. Id numbers that correspond to those memory locations identify the data records. The id numbers are not part of the record themselves. Several low-level functions are provided that per- form the management of the read/write and maintenance of the database, based on the number of records and record size. Some error codes are generated that can be called by users in their application codes. (The demonstration program shows some of the error checks in use). The data structure and error recovery as well as the low-level functions are described later. User API The EEPROM Emulation code is also provided with a sample demonstration program, which is used to input the user parameters to the main code. Four functions are provided to the user for EEPROM data management in this implementation. They are: ■ EEPROM_Format ■ Update_Record ■ Read_Record ■ EEPROM_Init Overall the algorithm performs the data management, in a way that is completely transparent to the appli- cation, using many low-level functions that augment this mechanism. The user is also responsible for defining the data record size (in bytes), and the maximum number of records allowed. Valid values are 0 to 65535 (0 to 0xFFFF) for the current implementation. These param- eters have to be defined at compile- and run-time The data record size is defined in eeprom.h prior to compile-time. For the supplied demonstration program it has been set to 128 bytes. (APPENDIX B.) The maximum number of records is defined at run time via an argument to EEPROM_Format. (In the sup- plied demonstration program it has been set to one record only (APPENDIX C.) A brief description and usage of the four functions, that are available to the user as input, are as follows: EEPROM_Format. This writes a sector header to sector 0, and erases sector 1. Note that a call to this function will erase any existing data. Part of the formatting process involves verifying that the maximum number of records and the record size are compatible with the sector size. (The demonstration program provides an error check to test if this is not met). The user needs to correlate id numbers to data entries based on the application. Update_Record. Data is written using this function. (The demonstration program uses this function to write the contents of a buffer) The function accepts an id number and a pointer to a data buffer. The user is responsible for initializing the data buffer to the correct number of data bytes. Data is updated using the same function. The program will create a linked list of data updates until the sector is full. At that point, only the valid data is written to a new sector, along with the sector header. This is transparent to the user. 3/25 AN2040 - APPLICATION NOTE Update_Record (BYTE id, BYTE *buf). This function adds/updates a record entry with new data. The id number corresponds to the location in memory of the initial data entry. The user can correlate the id num- ber with the data in any way he or she chooses. The user must provide a pointer to a data array in xdata containing the data for the record. This function passes the id number and data pointer to Write_Record. Write_Record will either update the parameter or return an error saying that the sector is full. In the case of a full sector, the data is saved to an intermediate buffer and Eeprom_Sector_Swap is called. Eeprom_Sector_Swap transfers all valid data entries to a new sector, including the current update. Read_Record. This function is used to read any record. (In the demonstration program, it read backs the record written by update record). This function accepts the id number of the record and a pointer to a buffer to receive the data. Once again, it is the users’ responsibility to set up a data buffer of the appropriate type and size. (For the demonstration program, this buffer is set to size 1) Read_Record (WORD id, BYTE *buffer). This function reads record data into a buffer provided by the user. Only the last update is read. The record is retrieved as follows: First, the active sector is retrieved using the function Find_Active_Sector. The base address of the record is then determined from the active sector number. The base record corresponding to the id is then read. If the base record is not the last up- date, the function enters a loop in which it reads the record entries until the last one is found. The data is then copied into the buffer pointed to by *buffer.