...

the world's most energy friendly microcontrollers

EEPROM Emulation
AN0019 - Application Note

Introduction

This application note demonstrates a way to use the flash memory of the EFM32 to
emulate single variable rewritable EEPROM memory through software. The example
API provided enables reading and writing of single variables to non-volatile flash
memory. The erase-rewrite algorithm distributes page erases and thereby doing
wear leveling.

This application note includes:

• This PDF document

• Source files (zip)
• Example C-code
• Multiple IDE projects
 ...the world's most energy friendly microcontrollers

1 General Theory
1.1 EEPROM and Flash Based Memory
EEPROM stands for Electrically Erasable Programmable Read-Only Memory and is a type of non-
volatile memory that is byte erasable and therefore often used to store small amounts of data that
must be saved when power is removed. The EFM32 microcontrollers do not include an embedded
EEPROM module for byte erasable non-volatile storage, but all EFM32s do provide flash memory for
non-volatile data storage. The main difference between flash memory and EEPROM is the erasable unit
size. Flash memory is block-erasable which means that bytes cannot be erased individually, instead a
block consisting of several bytes need to be erased at the same time. Through software however, it is
possible to emulate individually erasable rewritable byte memory using block-erasable flash memory.

To provide EEPROM functionality for the EFM32s in an application, there are at least two options
available. The first one is to include an external EEPROM module when designing the hardware layout
of the application. The other is to use the on-chip flash memory and emulate EEPROM functionality
through a software API. There are however some key differences between these two methods.

• First, the write access time for flash memory is shorter than for external EEPROM. This means that
writing to emulated EEPROM is faster than writing to an external EEPROM.
• Second, while a standalone EEPROM will be able to complete a write operation even if the system
is reset, the emulated EEPROM will need the CPU to be active throughout the entire flash operation.
This is an important difference. The consequences of an aborted flash operation should be taken into
account when designing an application. The flash based EEPROM emulation could use checksums
and logging to ensure the integrity of written data.
• Lastly the emulated EEPROM will regularly need to erase pages in flash, to free space and be able to
write to the same page more than once. On a standalone EEPROM there is no need for a dedicated
erase operation, since all bytes can be rewritten independently. Here it is also important to notice that
the flash erase operation will need the CPU to be running safely for the entire operation.

In addition to the risk of power failure or system reset aborting flash write or erase operations, one must
also handle internal sources like interrupts trying to execute code from flash. When writing to or erasing
flash, any concurrent attempts to access the flash will result in a hard fault exception and core lock up.
Any interrupts triggering while the CPU is performing operations on flash must therefore be executed
from RAM. This includes the interrupt vector, the interrupt vector table also needs to be relocated to
RAM. An alternative is just to disable any interrupts while performing the flash operations. This can be
done in software. Any interrupt that would have triggered during the flash operation, can be configured
to execute when the flash operation is complete, and interrupts again are enabled.

It should also be mentioned that in order to avoid any bus conflicts, all flash operations must be performed
with code from RAM. Attempts to initiate a flash operation from the flash itself, will result in the same
exception as the case with interrupts.

1.2 Flash Limitations

Flash memory is limited to a finite number of program-erase cycles. This means that the embedded
flash memory of the EFM32 can be erased only a certain number of times, before the wear will begin
to affect the integrity of the storage. This deterioration applies to all kinds of flash memory. All EFM32
MCUs are guaranteed to withstand a number of erase cycles. This number can be found in the data
sheet for each part.

All flash memory is divided into pages that each must be erased as single units. The amount of on-chip
flash memory and the page size found in the different EFM32 microcontrollers, varies depending on the
specific part. See the Reference Manual for more information about the page size.

2013-09-16 - an0019_Rev1.09 2 www.silabs.com

 ...the world's most energy friendly microcontrollers

Flash pages and words in each page are illustrated in Figure 1.1 (p. 3). Because the erase operation
erases only whole pages, it is important to write as much data as possible to a single page of flash,
before erasing the page.

Figure 1.1. Flash Pages and Words.

Flash Page 0
Page 0 FFFFFFFF
Page 1 FFFFFFFF
Page 2 FFFFFFFF
Page 3 FFFFFFFF
Page 4 FFFFFFFF
Page 5 FFFFFFFF 512 bytes =
Page 6 FFFFFFFF 128 words
Page 7 FFFFFFFF

Last Page FFFFFFFF

Figure 1.1 (p. 3) shows the flash, and how it is divided in pages that in turn are divided in 32 bit
words.

In general it is not possible to read from flash while writing or erasing a page. On the Gecko series
a read-while-write will result in a core lockup and hardfault. On newer devices like the Tiny or Giant
series a read will stall until the write or erase operation is finished. The Reference Manual documents
the behavior for each family.

This means that interrupts trying to execute from flash could potentially stall for a long time or even
cause a hardfault. A solution to this is to move interrupts that can be triggered during flash operations to
RAM. Code executing from is not affected by the flash operation. For this to work, the vector table itself
also has to be relocated to RAM. Another solution is to disable interrupts during the flash operation. Any
interrupts that occured during the flash operation will be triggered when interrupts are enabled again.

Note
On the Gecko family of devices any attempt to initiate a flash operation from the flash itself,
will result in the same exception as the case with interrupts. This means that for these
devices all flash operations must be performed with code from RAM.

2013-09-16 - an0019_Rev1.09 3 www.silabs.com

 ...the world's most energy friendly microcontrollers

2 Implementation
There are different ways to implement an EEPROM Emulator using flash memory. The idea behind the
example attached in this application note, is to allocate a certain number of pages of flash memory for
the entire lifetime of the application. The wear is then leveled among these by alternating which pages
are used. The number of pages allocated must reflect the amount of data that will be written throughout
the application lifetime.

2.1 Pages and Their States

In every page allocated to the EEPROM Emulator provided, the first word is reserved for page head
data. This head word contains the status of the page and the erase count.

The erase count is the number of times all pages have been erased. The erase count is incremented
each time the last page is erased and valid variables are transferred back to page 0. This completes
one erase cycle on all the flash pages allocated.

Each page will always be in one of three different states. Active, Receiving or Erased.

• After a page is erased, all bits in the entire page are 1's.
• When a page is receiving, it means that a transfer of variables from a full active page is in progress.
After the transfer is complete, the receiving page is made the new active one, and the old active page
is erased.
• The active page is the page that contains the currently valid data. All read and write operations are
made on the active page. There should never be more than one active or receiving page at any time
in this implementation.

Figure 2.1. EEPROM Emulation Page Status Flow.

Write/ Read data

Page 0 Active Page 1 Erased
to/ from page 0
Page 0 Full
Transfer data
Page 0 Active Page 1 Receiving
from page 0 to 1
Page 0 Erased

Page 0 Erased Page 1 Receiving Make page 1 active

Page 1 Activated
Write/ Read data
Page 0 Erased Page 1 Active
to/ from page 1
Page 1 Full
Transfer data
Page 0 Receiving Page 1 Active
from page 1 to 0
Page 1 Erased
Update erase count
Page 0 Receiving Page 1 Erased
Make page 0 active
Page 0 Activated

Figure 2.1 (p. 4) shows the state flow for a realization using 2 pages. The flow would be similar if
more pages are allocated, only more pages would be in the erased state simultaneously.

During initialization, the page status for the selected number of pages are checked, to ensure that a
legal set of page-states are obtained. If there are more than one of either the active or receiving pages,
or if all pages are erased, all pages are reset to a valid configuration and page 0 is the new active page.
Page 0 will be the last page in the flash memory, page 1 will be the second last etc. This minimizes

2013-09-16 - an0019_Rev1.09 4 www.silabs.com

 ...the world's most energy friendly microcontrollers

the probability for data collisions with program instructions, which are located at the base of the flash.
In applications where much of the available flash memory is in use, it can be critical to know where all
data is stored in the flash to avoid collisions. The ability to lock the flash from being written to can be a
nice feature in this context. Locking individual pages is done by clearing bits in the Lock Bit Page, for
further information see the reference manual for the device. Alternatively a memory protection algorithm
can be implemented in software.

The remaining words of each page, after the first Page Status Word, are free to be used for data storage.
Each data storage word is divided into two parts; one virtual address field and one data field. Each of
them are 16 bits wide in this example. Whenever a page is full, a page transfer is initiated. This operation
consists of several steps to always ensure that all variables are non-volatile in case of an external event.
First, an erased page is located to store the valid data present in the full page. This page is marked as
receiving. Next, the most recent data associated with each variable is transferred to the top of the new
page. When this is done, the old active page is erased, the erase count is written to the receiving page
header, lastly it is labeled as the new active page. This process is illustrated in Figure 2.2 (p. 5) .

Figure 2.2. EEPROM Emulation Variable Flow.

Page Status Erase Count Virtual Address Data Virtual Address Data
of var1 of var1 of var2 of var2

EE_Write(var2, 0x 1111);
EE_Write(var1, 0x 200);

Page 0 Page 1 Page 0 Page 1 Page 0 Page 1

00 000A31 FFFFFFFF 00 000A31 FFFFFFFF 00 000A31 FFFFFFFF
FFFFFFFF FFFFFFFF 0001 0200 FFFFFFFF 0001 0200 FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 001B 1111 FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
512 bytes = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
128 words FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF

FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF

EE_Write(var1, 0x 500);

Page 0 Page 1 Page 0 Page 1 Page 0 Page 1

00 000A31 FFFFFFFF 00 000A31 AA FFFFFF FFFFFFFF 00 000A31
Page 0 full

0001 0200 FFFFFFFF 0001 0200 0001 0500 FFFFFFFF 0001 0500
001B 1111 FFFFFFFF 001B 1111 001B 3333 FFFFFFFF 001B 3333
FFFFFFFF 0004 4AF1 FFFFFFFF 0004 4AF1
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0004 4AF0 0004 4AF0
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
001B 2222 001B 2222
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0001 0300 0001 0300
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
0004 4AF1 0004 4AF1
0001 0400 0001 0400
001B 3333 FFFFFFFF 001B 3333 FFFFFFFF FFFFFFFF FFFFFFFF

Figure 2.2 (p. 5) shows how the data is written to the pages, and how a the latest valid data is
transferred to an erased page when the active page is filled up.

2.2 Read and Write

Whenever data is to be written to a new variable, it should first be declared to give it a unique virtual
address. The virtual addresses makes the read operation able to determine what data belongs to which
variable. This is necessary since the variables are not stored on a constant absolute address, but
are moved around in flash memory to minimize wear. Reading consists of an iteration through the
active page, starting from the bottom. When the correct virtual address is found for the first time, the
corresponding data is returned as the currently valid data.

2013-09-16 - an0019_Rev1.09 5 www.silabs.com

 ...the world's most energy friendly microcontrollers

The write operation consists of a similar iteration, only that it is starting at the top of the active page.
When an empty word is found, the correct virtual address and data is written, and the function returns.
If no empty word is found, and the end of the page is reached, the page is considered full.

In this implementation all valid data has to fit in one page (the active page). The page size therefore puts
a direct limitation on the number of variables. Each variable uses 4 bytes (2 bytes for data and 2 bytes
for the virtual address) and 4 bytes per page is reserved for the Page Status Word.

Maximum EEPROM variables

Nmax = (PAGE_SIZE - 4) / 4 (2.1)

2.3 Flash Wear and Page Allocation

For an application that depends on regularly writing data to the non-volatile flash memory, the flash wear
limitation is not can be an important lifetime limiting factor.

A 512 byte page with 20k erase cycles, can be used to write a maximum of 10 megabytes throughout
the lifetime of the system. It is in this context important to have a good understanding of how much data
that will be written in the lifetime of the system to decide how many pages are needed.

In the software example attached, all variables are 16 bit data, with a 16 bit virtual address. This means
that all variables uses 4 bytes of flash memory each time new data is written, see Figure 2.2 (p. 5) .
Accordingly each page can take (PAGE_SIZE - 4) / 4 variable writes, before it is full. Each new page is
initially filled with the latest value of all currently valid variables and a head, before it can be written to.
This means that before any new value can be written to a variable on a new page, the page will already
have filled a space equal to the number of variables in use. To estimate the number of pages needed to
guarantee predictable flash operation throughout the application lifetime we have to make sure the total
number of page erase cycles does not exeed the guaranteed limit:

Page number calculations

TOTAL_WRITES / (Nmax - N + 1) < ERASE_LIMIT * NUM_PAGES (2.2)

Where N is the number of variables, TOTAL_WRITES is the number of total variable writes in the lifetime
of the system and ERASE_LIMIT is the number of flash erase cycles which are guaranteed to be safe.

Say for instance that a certain application is designed to update 7 different variables, every 5 minutes
for 8 years. The device is a Tiny Gecko with flash specified to handle at least 20000 erase cycles and
has 512 bytes page size.

This implies 7 * 8 * 365 * 24 * 12 = ~5.9 million word writes. The number of pages needed to guarantee
non-volatile storage of all this data, is:

NUM_PAGES > 5.9 * 10^6 / ( (512 - 4)/4) - 7 + 1 ) / 20000 = ~2.3

Thus at least 3 pages must be allocated for safe operation of this application.

2013-09-16 - an0019_Rev1.09 6 www.silabs.com

 ...the world's most energy friendly microcontrollers

3 Software Examples
The software example supplied, demonstrates a realization of an EEPROM emulator software API.

3.1 Data Granularity

In this example, the data and virtual address are each assigned 16 bits of space. This may not be
sufficient for some applications. The data granularity should therefore be adjusted according to the
requirements of the application. Different sets of common variable sizes could be implemented to allow
byte rewritable 8/8 bits data/virtual address variables, or full word 32/32 bits variables. It is important
to notice that this would also affect the wear and lifetime of the flash memory accordingly. It can for
example be noticed that even though 32+32 bits variables would be very useful in many settings, it will
more than halve the lifetime of the flash.

3.2 Initialization and Recovery

An important part of an EEPROM emulation software, is to ensure correct page state, and data recovery
on system startup. For this reason, the initialization function should be run near the start of the software,
before any data is written or read to/from any variables. The initializing function will decide how many
pages that are allocated to the emulator, it will then check the head of each of these pages to ensure
that the set of pages are valid. The valid sets are:

• One receiving and one active page.

• Data will be transferred from the active to the receiving page. The active page will be erased, and
the receiving page will be marked active.
• Exactly one receiving page.
• The receiving page will be marked as the new active page.
• Exactly one active page.
• No action is required.

In addition, pages marked as erased are checked to verify that they really are erased.

If an invalid set of pages is found, either if all are erased or there are more than one of the active or
receiving, the set of pages will be formatted. This should usually only happen the first time the software
is executed on a MCU with old data present. On a format, all pages are erased and page 0 is set to be
the active one. More advanced functionality could be added, recovering some data in case a fatal error
corrupts the page headers during normal operation of the system.

3.3 Additional Considerations

The EEPROM emulation example can run on both the STKs and DVK with both plug-in cards. Some
consideration should however be given to ensure that the required number of pages can be allocated
without any conflict with the application binary file located at the beginning of the flash. This could be a
problem with parts low on flash memory, or if too many pages are allocated during initialization.

2013-09-16 - an0019_Rev1.09 7 www.silabs.com

 ...the world's most energy friendly microcontrollers

4 Revision History
4.1 Revision 1.09
2013-09-03

New cover layout

4.2 Revision 1.08

2013-05-08

Added software projects for ARM-GCC and Atollic TrueStudio.

4.3 Revision 1.07

2013-02-14

Fixed a bug which would cause EE_Init() to return false even if the pages were valid

4.4 Revision 1.06

2012-12-10

Fixed a bug which could case wrong flash pages to be erased. Thanks to Stefan Pachner for reporting
this bug.

Added support for devices with larger page sizes

Added support for interrupts during flash access

Moved format function out of init

4.5 Revision 1.05

2012-11-12

Adapted software projects to new kit-driver and bsp structure.

Added projects for Tiny and Giant Gecko STKs.

Fixed ram function problems for the other compilers than IAR.

4.6 Revision 1.04

2012-04-20

Adapted software projects to new peripheral library naming and CMSIS_V3.

4.7 Revision 1.03

2011-10-21

Updated IDE project paths with new kits directory.

4.8 Revision 1.02

2011-05-18.

2013-09-16 - an0019_Rev1.09 8 www.silabs.com

 ...the world's most energy friendly microcontrollers

Updated projects to align with new bsp version.

4.9 Revision 1.01

2010-11-16

Changed example folder structure, removed build and src folders.

Updated chip init function to newest efm32lib version.

Updated register defines in code to match newest efm32lib release.

4.10 Revision 1.00

2010-09-21

Initial revision.

2013-09-16 - an0019_Rev1.09 9 www.silabs.com

 ...the world's most energy friendly microcontrollers

A Disclaimer and Trademarks

A.1 Disclaimer
Silicon Laboratories intends to provide customers with the latest, accurate, and in-depth documentation
of all peripherals and modules available for system and software implementers using or intending to use
the Silicon Laboratories products. Characterization data, available modules and peripherals, memory
sizes and memory addresses refer to each specific device, and "Typical" parameters provided can and
do vary in different applications. Application examples described herein are for illustrative purposes
only. Silicon Laboratories reserves the right to make changes without further notice and limitation to
product information, specifications, and descriptions herein, and does not give warranties as to the
accuracy or completeness of the included information. Silicon Laboratories shall have no liability for
the consequences of use of the information supplied herein. This document does not imply or express
copyright licenses granted hereunder to design or fabricate any integrated circuits. The products must
not be used within any Life Support System without the specific written consent of Silicon Laboratories.
A "Life Support System" is any product or system intended to support or sustain life and/or health, which,
if it fails, can be reasonably expected to result in significant personal injury or death. Silicon Laboratories
products are generally not intended for military applications. Silicon Laboratories products shall under no
circumstances be used in weapons of mass destruction including (but not limited to) nuclear, biological
or chemical weapons, or missiles capable of delivering such weapons.

A.2 Trademark Information

Silicon Laboratories Inc., Silicon Laboratories, the Silicon Labs logo, Energy Micro, EFM, EFM32, EFR,
logo and combinations thereof, and others are the registered trademarks or trademarks of Silicon
Laboratories Inc. ARM, CORTEX, Cortex-M3 and THUMB are trademarks or registered trademarks
of ARM Holdings. Keil is a registered trademark of ARM Limited. All other products or brand names
mentioned herein are trademarks of their respective holders.

2013-09-16 - an0019_Rev1.09 10 www.silabs.com

 ...the world's most energy friendly microcontrollers

B Contact Information
Silicon Laboratories Inc.
400 West Cesar Chavez
Austin, TX 78701

Please visit the Silicon Labs Technical Support web page:

http://www.silabs.com/support/pages/contacttechnicalsupport.aspx
and register to submit a technical support request.

2013-09-16 - an0019_Rev1.09 11 www.silabs.com

 ...the world's most energy friendly microcontrollers

Table of Contents
1. General Theory ......................................................................................................................................... 2
1.1. EEPROM and Flash Based Memory .................................................................................................. 2
1.2. Flash Limitations ............................................................................................................................. 2
2. Implementation ......................................................................................................................................... 4
2.1. Pages and Their States ................................................................................................................... 4
2.2. Read and Write .............................................................................................................................. 5
2.3. Flash Wear and Page Allocation ........................................................................................................ 6
3. Software Examples .................................................................................................................................... 7
3.1. Data Granularity ............................................................................................................................. 7
3.2. Initialization and Recovery ................................................................................................................ 7
3.3. Additional Considerations ................................................................................................................. 7
4. Revision History ........................................................................................................................................ 8
4.1. Revision 1.09 ................................................................................................................................. 8
4.2. Revision 1.08 ................................................................................................................................. 8
4.3. Revision 1.07 ................................................................................................................................. 8
4.4. Revision 1.06 ................................................................................................................................. 8
4.5. Revision 1.05 ................................................................................................................................. 8
4.6. Revision 1.04 ................................................................................................................................. 8
4.7. Revision 1.03 ................................................................................................................................. 8
4.8. Revision 1.02 ................................................................................................................................. 8
4.9. Revision 1.01 ................................................................................................................................. 9
4.10. Revision 1.00 ............................................................................................................................... 9
A. Disclaimer and Trademarks ....................................................................................................................... 10
A.1. Disclaimer ................................................................................................................................... 10
A.2. Trademark Information ................................................................................................................... 10
B. Contact Information ................................................................................................................................. 11
B.1. ................................................................................................................................................. 11

2013-09-16 - an0019_Rev1.09 12 www.silabs.com

 ...the world's most energy friendly microcontrollers

List of Figures
1.1. Flash Pages and Words. .......................................................................................................................... 3
2.1. EEPROM Emulation Page Status Flow. ...................................................................................................... 4
2.2. EEPROM Emulation Variable Flow. ............................................................................................................ 5

2013-09-16 - an0019_Rev1.09 13 www.silabs.com

 ...the world's most energy friendly microcontrollers

List of Equations
2.1. Maximum EEPROM variables ................................................................................................................... 6
2.2. Page number calculations ........................................................................................................................ 6

2013-09-16 - an0019_Rev1.09 14 www.silabs.com