Generation 3 C2000 MCUs come with different configurations of Flash memory that is arranged in multiple sectors. Unfortunately, the technology used for the on-chip Flash memory does not allow adding a traditional EEPROM on the chip. Some designers use an external EEPROM part for such non-volatile storage. The good news is that Flash memory is a specific type of EEPROM and all Generation 3 C2000 MCUs have in-circuit programming ability for the Flash memory. This application report makes use of this facility and allows using sectors of on-chip Flash as EEPROM by emulating the EEPROM functionality within the limitations of the Flash memory. Note that at least one Flash sector is entirely used as an emulated EEPROM; therefore, it is not available for the application code.

EEPROMs are available in different capacities and connect with the host microcontrollers via a serial and sometimes parallel interface. The serial inter-integrated circuit (I2C) and serial peripheral interface (SPI) are quite popular due to the minimal number of pins/traces. EEPROMs can be programmed and erased electrically and most of the serial EEPROMs allow byte-by-byte program or erase operations.

The major difference between EEPROM and Flash operations is seen in the erase operation. The EEPROM does not require a sector erase operation. One can erase a particular byte requiring the specified time. However, the smallest unit of an erase operation in Flash is one sector.

Flash erase and write cycles are performed by applying time-controlled voltages to each cell. In the erase condition, each cell (bit) reads logical 1. Therefore, every Flash location of a C2000 Real-Time Controller reads 0xFFFF when erased. Through programming, the cell can be changed to logical 0. Any word can be overwritten to change a bit from logical 1 to 0 (assuming corresponding ECC has not been programmed); but not the other way around. The on-chip Flash memory on Generation 3 C2000 MCUs parts require TI-supplied specific algorithms (Flash API) for erase and write operations.

The implementation described in this document supports both Single-Unit and Ping-Pong EEPROM Emulation. Single-Unit and Ping-Pong implementations both support two modes, Page-Programming and 64-Bit Programming mode. Ping-Pong Emulation will be described first, and Single-Unit will be described subsequently.

There are multiple user-configurable EEPROM variables supported by this implementation. These variables are detailed in Section 5.1.

In this implementation, the emulated EEPROM is comprised of at least one Flash Sector. Due to the block erase requirement of Flash, a Flash sector has to be entirely reserved for the EEPROM Emulation. Based on the C2000 part number, the size of the Flash sector will vary. The area of the Flash sector is divided into a number of smaller sections and is referred to as a Page. For example, a 2K x 16 flash sector can be divided into 32 pages, each with a size of 64 x 16.

The data to be saved is first written in a buffer in RAM. Then, using the in-circuit programming facility of Generation 3 C2000 MCUs, the data is written to the first page in the selected sector(s) for EEPROM Emulation. The next time data is written to Flash, it will be written to the next page. This process continues until the last page in the selected sector is written. Upon reaching the last page, there are two ways to continue. If using Single-Unit EEPROM emulation, see the Single-Unit Emulation behavior to see how this is handled. If using Ping Pong EEPROM Emulation, see Ping-Pong Method to see how this is handled.

In addition to the Page Programming concept described above, there is also support for 64-Bit Programming. In this mode, the sectors is not broken into EEPROM banks and pages. 64-Bit Programming is discussed further in Section 5.2.9 and Section 5.2.10 .

If using Single-Unit EEPROM Emulation, Figure 3-1 shows the implemented behavior.

Figure 3-1 Single-Unit Behavior

If the EEPROM unit is full and there is more data to be written, the EEPROM unit is erased and the new data is programmed to Flash. This process can be repeated as necessary.

If using the Ping Pong method, the following diagram shows the implemented behavior. As shown in Figure 3-2, there are two EEPROM units made up of selected Flash Sectors. One is marked as an Active Unit, and the other is marked as the Inactive Unit. To begin, data is written to the Active Unit.

Figure 3-2 Ping Pong Behavior

If the Active Unit is full and there is more data to be written, the Active and Inactive EEPROM units will switch. Therefore, the previously Active Unit (full Unit) will be marked as Inactive, and the previously Inactive Unit (empty Unit) will be marked as Active. Subsequently, the data will be written to the newly Active EEPROM Unit. After the data is successfully programmed to the Active EEPROM Unit, the Inactive EEPROM Unit is erased. This method ensures that there is a fall-back options for the last successfully written data in case of any failure during the erase or program operation when the currently active EEPROM Unit is full.

This process can be repeated as necessary.

In order to support EEPROM emulation with varying data sizes (other than 64-bits), the Flash Sectors selected for emulation are divided into a format referred to as EEPROM Banks (not to be confused with Flash Banks) and Pages. First, the Flash sector (or set of chosen Flash Sectors) is divided into EEPROM banks. Each EEPROM bank is further divided into Pages. This partitioning is shown in Bank Partitioning. The partitioning of EEPROM Banks and Pages is the same for Single-Unit and Ping-Pong emulation.

Using this format allows the application to:

• Read back the data from the page written during the previous save
• Write the latest data to a new page
• Read from any previously stored data, if required by the application

Figure 3-3 Bank Partitioning

The first eight 16-bit words of each EEPROM bank are reserved for EEPROM bank status information and the first eight words of each page are reserved for page status information. Every time a new set of data is written to a page, the status location of the last page and the next page are modified. When a new EEPROM bank is used the Bank Status of the last and current EEPROM banks are updated. Both the EEPROM Bank and Page status words differentiate between the current EEPROM Bank/Page and a used EEPROM Bank/Page in the same way. To mark an EEPROM Bank or Page as current, the first 64-bits are written with the appropriate status code. To mark an EEPROM Bank or Page as full, the latter 64-bits are written with the appropriate status code. More details about the status codes can be found in the EEPROM_GetValidBank.

As seen in Page Layout, all pages contain an eight-word page status and a configurable amount of data space. Page 0 is slightly different as it contains the EEPROM bank status as well. Only Pages 0 and 1 are shown, but it should be noted that Page 2 through Page (N-1) are identical to Page 1.

Figure 3-4 Page Layout

The software provided with this application report includes EEPROM Emulation source code for the F28P65x Generation 3 C2000 Real-Time Controller with an example project demonstrating how to utilize the source code. Some aspects of the code may differ based on the device being used. For an example, see the Adapting to Other Gen 3 C2000 MCUs. The rest of the guide is designed for the F28P650DK9.

This software provides basic EEPROM functionality: write, read, and erase. At least one sector of Flash memory is used to emulate EEPROM. This sector(s) is broken into several EEPROM banks and pages, each containing status words to determine the validity of the data as described above.

This code uses the Header Files and Flash API libraries provided for the F28P65x. The example code can be found within the C2000Ware Directory. The full path is: C2000Ware_5_00_00_00/driverlib/f28p65x/examples/c28x/flash.

The device must first go through its initialization code to initialize clocks, peripherals, and so forth. The initialization functions used are the functions provided with the header library files included in the project. Further information regarding this sequence can be read in the documentation provided with the header files.

Once this is complete, the Flash API initialization and parameters are set to prepare for Flash programming. The Flash API library requires a few files and certain initialization/setup to function properly. The complete list of required steps can be found in the F28P65x Flash API Reference Guide.

Next, the EEPROM Configuration specified by the user in EEPROM_Config.h will be checked for validity and certain variables used by the Flash API will be configured. More details can be found in User-Configuration and Section 5.2.1.

At this point, programming can begin. First, data needs to be captured to program. After programming this data, the read functionality reads the last set of data that was programmed into the Flash. This software flow should be followed by most applications, especially the initialization portion as some Flash API functions need to be copied to internal RAM before programming can begin.

The example project provided follows this software flow shown in Software Flow. To learn more about the functions shown in the diagram, navigate to their appropriate section in the document.

Figure 4-1 Software Flow

In this section, the Ping-Pong implementation are discussed. To review the behavior of this implementation, see Ping Pong Behavior.

The implementation detailed in this document allows the user to configure several variables for EEPROM Emulation. These variables are mainly found within EEPROM_Config.h, but two are contained in F28P65x_EEPROM.c. The configurable variables will be discussed below in the section dedicated to the appropriate file.

EEPROM_Config.h contains definitions that allow the user to change various aspects of EEPROM configuration. These aspects include:

• Define which device variant is being used. This allows EEPROM emulation in Flash Banks not common to all devices.

// Un-comment appropriate definition if one of the following variants is being used
#define F28P65xDKx 1
//#define F28P65xSKx 1
//#define F28P65xSHx 1

• Choose between Page Mode and 64-Bit Mode.

//#define _64_BIT_MODE 1
#define PAGE_MODE 1

• Choose which Flash Bank to use for emulation. The Flash API and program are stored/run from Flash Bank 0 by default, so it cannot be used for EEPROM Emulation. In general, the Flash API and program should be stored/run from a different Flash bank than the ones used for EEPROM emulation.

#define FLASH_BANK_SELECT FlashBank1StartAddress

• Define the Flash Sector size (unit is 16-bit words). This will vary based on the device being used, reference the appropriate data sheet for details.

#define FLASH_SECTOR_SIZE F28P65x_FLASH_SECTOR_SIZE

• Define how many Flash sectors are in a Flash Bank. This will vary based on the device being used, reference the appropriate data sheet for details.

#define NUM_FLASH_SECTORS F28P65x_NUM_FLASH_SECTORS

• Choose how many EEPROM Banks to emulate.

#define NUM_EEPROM_BANKS 4

• Choose how many EEPROM Pages within each EEPROM Bank

#define NUM_EEPROM_PAGES 3

• Choose the size of the data space contained within each EEPROM Page (unit is 16-bit words). Although any size can be specified, the size will be adjusted to the closest multiple of four that is greater than or equal to the size specified. For example, a specified size of six 16-bit words per page will be programmed as eight 16-bit words per page, with the last two being treated as 0xFFFF. This is to comply with Flash requirements (8-bit ECC is programmed for every 64-bit aligned Flash memory address).

#define DATA_SIZE 64

Within F28P65x_EEROM.c, users can choose which Flash Sectors to use for EEPROM emulation. The sectors chosen (if multiple) should be contiguous and in order from least to greatest. Insert only the First and Last sectors to be used for EEPROM. For example, to use sectors 1-10, insert {1,10}. To only use sector 1, insert {1,1}. A valid configuration has the following properties.

• Imply a valid and consistent amount of sectors between the two EEPROM units
• Only include a sector(s) that exist on the device
• Not create an overlap in the Write/Erase Protection Masks between the two units
  • The F28P65x Flash API requires Write/Erase Protection Masks to be configured before programming Flash Memory. Details about the proper configuration of these masks can be found in the F28P65x Flash API Reference Guide.

More details about invalid or dangerous configurations can be found in Section 5.2.1.

uint16 FIRST_AND_LAST_SECTOR[2][2] = {{1,1},{39,39}};

Additionally, you can choose which set of Flash Sectors to begin emulation in.

uint16 EEPROM_ACTIVE_UNIT = 0;

If set to 0, the first set of Flash Sectors in FIRST_AND_LAST_SECTOR will be the Active EEPROM Unit first, and the second set will be Inactive EEPROM unit at first. If set to 1, the opposite will be true.

To implement this functionality, 11 functions are required to configure, program, read, and erase in Page programming. Two additional functions are needed for 64-bit programming. All functions are included in the F28P65x_EEPROM.c or F28P65x_EEPROM_PingPong.c file.

• EEPROM_Config_Check()
• Configure_Protection_Masks(Uint16* Sector_Numbers, Uint16 Num_EEPROM_Sectors)
• EEPROM_Write(Uint16* Write_Buffer)
• EEPROM_Read(Uint16* Read_Buffer)
• EEPROM_Erase( )
• Erase_Bank( )
• EEPROM_GetValidBank(Uint16 Read_Flag)
• EEPROM_UpdateBankStatus( )
• EEPROM_UpdatePageStatus( )
• EEPROM_Get_64_Bit_Data_Address()
• EEPROM_Program_64_Bits(Uint16 Num_Words)
• EEPROM_CheckStatus(Fapi_StatusType* oReturnCheck);
• ClearFSMStatus()

The description of each of these functions is discussed in detail in the subsequent sections.