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

2. Serial EEPROM vs. Flash EEPROM emulation
18 September 2018

3. 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

4. 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
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

5. 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

6. Flash EEPROM Emulation Methodology
18 September 2018

7. 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

8. 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

9. 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

10. 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

11. 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 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

12. 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 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

13. Flash EEPROM Emulation Methodology – Link List
Address Sector 1
0x0000
Sector Status (active)
Index
record (n-Bytes)
0x0008
0xFFFF 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

14. 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
0x 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

15. 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
0x ecc
old record 1
0x0010
0x ecc
old record 2
0x0018
0x0020
0x ecc
old record 4
0x0028
0x ecc
old record 5
0x0030
0xFFFF 0006 FF
valid record 6
...
0x0100
0x ecc
0x0108
0x 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

16. Flash EEPROM Emulation Methodology – Link List
Address Sector 1
0x0000
Sector Status (active)
Index
record (n-Bytes)
0x0008
0x ecc
old record 1
0x0010
0x ecc
old record 2
0x0018
0x0020
0x ecc
old record 4
0x0028
0x ecc
old record 5
0x0030
0xFFFF 0006 FF
valid record 6
...
0x0100
0x ecc
0x0108
0x 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

17. Flash EEPROM Emulation Methodology – Link List
Sector 1
Sector 2
Sector Status (0x FFFFFFFF) active
Index
record
0x ecc
old record
0x ecc
0x010C 0004 ecc
0x ecc
0x ecc
0xFFFF 0001 FF
valid record 1
0x ecc
0x ecc
0x ecc
0xFFFF 0002 FF
valid record 2
0x ecc
0x ecc
0x ecc
0xFFFF 0004 FF
valid record 4
Sector Status (0x00000A3FFFFFFFFF) copy
Index
record
0xFFFF 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
0x FFFFFFFF: active sector
0x : ready for erase
18 September 2018

18. 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 (0x FFFFFFFF) active
Index
record
0xFFFF 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
0x FFFFFFFF: copy sector
0x : ready for erase
18 September 2018

19. 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

20. Flash EEPROM Space and Customer Requirements
18 September 2018

21. Flash EEPROM Space and Customer Requirements
Generally, customer requirements are stated as ‘x’ ‘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

22. 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) = Byte Cycles
Normalize to Flash capabilities to determined how much Flash is needed:
Flash Size = Byte Cycles/100k W/E cycles = / = 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

23. 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 = Bytes Cycles
Normalize to Flash capabilities to determined how much Flash is needed:
Flash Size = Byte Cycles/100k W/E cycles = / = 64KBytes
64KBytes is the maximum Flash required to support a 2kByte block of data.
18 September 2018

24. 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

25. Flash EEPROM Emulation Summary
18 September 2018

26. 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