Flash EEPROM Emulation Concepts Practical Application of Flash EEPROM emulation 18 September 2018

Serial EEPROM vs. Flash EEPROM emulation 18 September 2018

Serial EEPROM vs. Flash EEPROM emulation Why EEPROM: EEPROM is generally used within an application to store application specific data such as diagnostic, calibration, event oriented, tracking information, etc. EEPROM provides an effective repository for this information due to its ease of access and programmability as well as its endurance characteristics. ECU Trends: As cost and quality pressures mount, there are increased calls to reduce component content within their ECU’s. Absorbing the EEPROM functionality within the MCU is a logical step that eliminates the external EEPROM component and communication mechanism to program the external memory space (SPI or I2C). TI Automotive TI Automotive 18 September 2018

Serial EEPROM vs. Flash EEPROM emulation What is Flash EEPROM Emulation: Using the MCU flash for data storage by means of a software driver that can manage the inefficiencies of flash such that a similar functionality as EEPROM is provided. Key differences between EEPROM and Flash: Feature EEPROM Flash EEPROM emulation Write Access 4-5mS + communication overhead <100uS Erase Not required 100-200 ms per sector (65nm node) CPU utilization Communication driver initiates the process, but reading and writing are CPU independent after initiated Low level driver must be accommodated to initiate and control the write and erase processing. Durability 1 Million w/e cycles 100K w/e cycles 18 September 2018

Serial EEPROM vs. Flash EEPROM emulation Flash EEPROM emulation challenges Data Management Write/Erase cycle management Data integrity Access timing Flash space efficiency/Flash utilization 18 September 2018

Flash EEPROM Emulation Methodology 18 September 2018

Flash EEPROM Emulation Methodology Dedicated EEPROM emulation flash bank EEPROM write/erase access while code executed from other Bank Multiple sectors per EEPROM emulation flash bank Uniform usage of sectors and hence optimum write/erase stress Sectors are used in a circular manner No data lost at unexpected power loss Valid data is copied into next sector at end of active sector before status bits are updated All EEPROM locations are protected by SECDED Error Correcting Codes Flash Bank N-1 ... Flash Bank 1 Flash Bank 0 Interrupt Vectors, Rest Vectors, Exception, Program EEPROM Emulation Sector 0 Sector 1 Sector M-1 18 September 2018

Flash EEPROM Emulation Methodologies Linked list approach with index and data fields Flexible scheme (occurrence of different entries, data size) Optimum utilization of sector Index used as identifier (data in/-valid), block address, ecc padding and link to next entry Sector header contains implementation specific data like sector status bits, write counter, etc. Sector status to identify active, empty, invalid sectors, and an ongoing copy process Initialization routine to setup header of an empty sector EEPROM Flash Bank Sector 0 (status) Address Sector 1 0x0000 - - - - - - 0x0008 Sector Header Sector Status Bits Address Offset Block Address Ecc Padding Data Packet record (n-Bytes) 14bit / 16bit 10 bit / 16 bit 8 bit 32 bit / 16 bit record y Sector 1 (status) Record Header ... Sector M-1 (status) Physical memory address Data indexing & status records 18 September 2018

Flash EEPROM Emulation Methodology – Link List Address Sector 1 - Sector 1 empty after erase - Initialized sector header and list pointer 0x0000 Sector Status (empty) - - - - - - Index record (n-Bytes) 0x0008 0xFFFF FFFF FF empty 0x0010 0x0018 0x0020 Empty 0x0028 0x0030 ... 0x0100 0x0108 0x0110 0x0118 0x1000 0x1008 0x1010 0x1018 Pointer 18 September 2018

Flash EEPROM Emulation Methodology – Link List Address Sector 1 - Write record #1 to 1st empty location - Update block address 0xFFFF (empty) to 0x0001 (entry 1). 0x0000 Sector Status (active) - - - - - - Index record (n-Bytes) 0x0008 0xFFFF 0001 FF valid record 1 0x0010 0xFFFF FFFF FF empty 0x0018 0x0020 0x0028 0x0030 ... 0x0100 0x0108 0x0110 0x0118 0x1000 0x1008 0x1010 0x1018 Pointer 18 September 2018

Flash EEPROM Emulation Methodology – Link List Address Sector 1 - Write record #2 to next empty location - Update index status bits 0x0000 Sector Status (active) - - - - - - Index record (n-Bytes) 0x0008 0xFFFF 0001 FF valid record 1 0x0010 0xFFFF 0002 FF valid record 2 0x0018 0x0020 0xFFFF FFFF FF empty 0x0028 0x0030 ... 0x0100 0x0108 0x0110 0x0118 0x1000 0x1008 0x1010 0x1018 Pointer 18 September 2018

Flash EEPROM Emulation Methodology – Link List Address Sector 1 - Fill sector with different records and update corresponding index status bits 0x0000 Sector Status (active) - - - - - - Index record (n-Bytes) 0x0008 0xFFFF 0001 FF valid record 1 0x0010 0xFFFF 0002 FF valid record 2 0x0018 0x0020 0xFFFF 0004 FF valid record 4 0x0028 0xFFFF 0005 FF valid record 5 0x0030 0xFFFF 0006 FF valid record 6 ... 0x0100 0xFFFF FFFF FF empty 0x0108 0x0110 0x0118 0x1000 0x1008 0x1010 0x1018 18 September 2018

Flash EEPROM Emulation Methodology – Link List Address Sector 1 0x0000 Sector Status (active) - - - - - - Index record (n-Bytes) 0x0008 0xFFFF 0001 FF valid record 1 0x0010 0xFFFF 0002 FF valid record 2 0x0018 0x0020 0xFFFF 0004 FF valid record 4 0x0028 0xFFFF 0005 FF valid record 5 0x0030 0xFFFF 0006 FF valid record 6 ... 0x0100 0xFFFF 0001 FF 0x0108 0xFFFF FFFF FF empty 0x0110 0x0118 0x1000 0x1008 0x1010 0x1018 - New version of record #1 Same record Pointer 18 September 2018

Flash EEPROM Emulation Methodology – Link List Address Sector 1 - Update index with link to new version of record - Previous version of record is invalid 0x0000 Sector Status (active) - - - - - - Index record (n-Bytes) 0x0008 0x0100 0001 ecc old record 1 0x0010 0xFFFF 0002 FF valid record 2 0x0018 0x0020 0xFFFF 0004 FF valid record 4 0x0028 0xFFFF 0005 FF valid record 5 0x0030 0xFFFF 0006 FF valid record 6 ... 0x0100 0xFFFF 0001 FF valid record 1 0x0108 0xFFFF FFFF FF empty 0x0110 0x0118 0x1000 0x1008 0x1010 0x1018 14-bit address offset points to new 64-bit aligned address, giving 128KB EEPROM address space. 18 September 2018

Flash EEPROM Emulation Methodology – Link List Address Sector 1 - Fill list with records and links to the latest versions 0x0000 Sector Status (active) - - - - - - Index record (n-Bytes) 0x0008 0x0100 0001 ecc old record 1 0x0010 0x1008 0002 ecc old record 2 0x0018 0x0020 0x0108 0004 ecc old record 4 0x0028 0x0110 0005 ecc old record 5 0x0030 0xFFFF 0006 FF valid record 6 ... 0x0100 0x1000 0001 ecc 0x0108 0x0118 0004 ecc 0x0110 0xFFFF 0005 FF valid record 5 0x0118 0xFFFF 0004 FF valid record 4 0x1000 0xFFFF 0001 FF valid record 1 0x1008 0xFFFF 0002 FF valid record 2 0x1010 0x1018 0xFFFF FFFF FF empty 18 September 2018

Flash EEPROM Emulation Methodology – Link List Address Sector 1 0x0000 Sector Status (active) - - - - - - Index record (n-Bytes) 0x0008 0x0100 0001 ecc old record 1 0x0010 0x1008 0002 ecc old record 2 0x0018 0x0020 0x0108 0004 ecc old record 4 0x0028 0x0110 0005 ecc old record 5 0x0030 0xFFFF 0006 FF valid record 6 ... 0x0100 0x1000 0001 ecc 0x0108 0x0118 0004 ecc 0x0110 0xFFFF 0005 FF valid record 5 0x0118 0xFFFF 0004 FF valid record 4 0x1000 0xFFFF 0001 FF valid record 1 0x1008 0xFFFF 0002 FF valid record 2 0x1010 0x1018 0xFFFF FFFF FF empty 1 Entry point 2 Links to later versions of record 3 4 Access of latest data- set version 18 September 2018

Flash EEPROM Emulation Methodology – Link List Sector 1 Sector 2 Sector Status (0x00000000FFFFFFFF) active Index record 0x0100 0005 ecc old record 0x0106 0010 ecc 0x010C 0004 ecc 0x0112 0001 ecc 0x0212 0003 ecc 0xFFFF 0001 FF valid record 1 0x0306 0013 ecc 0x0506 0013 ecc 0x0312 0001 ecc 0xFFFF 0002 FF valid record 2 0x0512 0003 ecc 0x0518 0004 ecc 0x0906 0010 ecc 0xFFFF 0004 FF valid record 4 Sector Status (0x00000A3FFFFFFFFF) copy Index record 0xFFFF 0001 FF valid record 1 0xFFFF 0002 FF valid record 2 0xFFFF 0004 FF valid record 4 0xFFFF FFFF FF empty - Set sector 2 status to copy - Copy valid records into next sector Sector Status Legend: 0xFFFFFFFFFFFFFFFF: invalid sector 0x0017FFFFFFFFFFFF: empty sector 0x00000A3FFFFFFFFF: copy sector 0x00000000FFFFFFFF: active sector 0x0000000000000000: ready for erase 18 September 2018

Flash EEPROM Emulation Methodology – Link List Sector 1 Sector 2 - After copy process succeeded, set sector 2 status to “active” - Set sector 1 status to “ready for erase” - Start erase of sector - Erase can be done in an incremental manner and may last several seconds - After erase succeeds, set sector 1 status to “empty” Sector Status (0x1) invalid Index record 0xFFFF empty 0xXXXX old record Sector Status (0x00000000FFFFFFFF) active Index record 0xFFFF 0001 FF valid record 1 0xFFFF 0002 FF valid record 2 0xFFFF 0004 FF valid record 4 0xFFFF empty erase in progress Sector Status Legend: 0xFFFFFFFFFFFFFFFF: invalid sector 0x0017FFFFFFFFFFFF: empty sector 0x00000A3FFFFFFFFF: active sector 0x00000000FFFFFFFF: copy sector 0x0000000000000000: ready for erase 18 September 2018

Flash EEPROM Emulation Methodology – ECC Considerations Sector Header The sector header is 64 bits long so that is checked by one ECC byte. All valid values of the sector header have the same ECC byte value. (The sector header can be updated without changing the ECC value.) Record Header 8 ECC padding bits are added to the record header so that when the record header is updated to point to a new record, the 8 padding bits are programmed so that the true ECC bits do not change. 18 September 2018

Flash EEPROM Space and Customer Requirements 18 September 2018

Flash EEPROM Space and Customer Requirements Generally, customer requirements are stated as ‘x’ Kbytes @ ‘y’ write/erase cycles with byte, word, or long access. Often, there are multiple blocks defined with each having a specific cycle count requirement. Since the cycle requirements for the block(s) are often much higher than the maximum cycle capability of flash, it can be a challenge to determine the required flash size and sectoring scheme needed to support the customer requirement. 18 September 2018

Flash EEPROM Space and Customer Requirements How much Flash is needed? A simple view is to determine the total required cycles for a block of data and normalize to the write erase cycles supported by the flash cell. This identifies the minimum possible Flash needed to support the requirement. Byte Cycles = (Block Size * Required W/E Cycles) Given 2kBytes w/ 400k w/e cycles: Byte Cycles = (2kBytes * 400k Cycles) = 819200000 Byte Cycles Normalize to Flash capabilities to determined how much Flash is needed: Flash Size = Byte Cycles/100k W/E cycles = 819200000/100000 = 8kBytes 8KBytes is the minimum Flash required to support a 2kByte block of data. Note that there is no algorithm overhead accounted for in this analysis which necessitates writing all 2kbytes of data at once. 2kBytes 2kBytes 2kBytes 2kBytes 18 September 2018

Flash EEPROM Space and Customer Requirements How much Flash is needed? To understand the maximum amount of flash necessary, the analysis must also accommodate algorithm overhead based on the minimum customer write access. Given 2kBytes w/ 400k w/e cycles with Byte write access: Byte Cycles = (Block Size + Overhead)* W/E Cycles Where: Overhead = 7 bytes/minimum access size Byte Cycles = (2kBytes+2kBytes*7)*400k = 6400000000 Bytes Cycles Normalize to Flash capabilities to determined how much Flash is needed: Flash Size = Byte Cycles/100k W/E cycles = 6400000000/100000 = 64KBytes 64KBytes is the maximum Flash required to support a 2kByte block of data. 18 September 2018

Flash EEPROM Space and Customer Requirements How much flash is needed? 8k ? 64k Application Need Calculating a minimum and a maximum flash size to satisfy a customer requirement is straight forward as shown in prior slides. To determine the true size required is more difficult and is dependent on additional application requirements. Basic Factors: Additional Factors: Block Size Write/Erase Cycles Smallest Write Access/Data Granularity Safety Requirements (Data Retention Requirements, ECC, etc.) Breakdown of data structures Variation in Block Size and Write/Erase Cycle requirements 18 September 2018

Flash EEPROM Emulation Summary 18 September 2018

Flash EEPROM Emulation Summary Inherent Differences Between Flash And EEPROM requires a software algorithm to manage the data writes Effective management of Flash write/erase cycles requires a method to minimize erase cycles while maximizing write cycles (Link List) Determination of the required flash memory to emulate EEPROM is dependent on many factors including the physical attributes of the data as well as safety and application specific attributes Flash EEPROM emulation can be a net gain for both TI and the customer by adding value to the product while removing cost for the customer. 18 September 2018