STM32f103 Eprom emulation

[SGasp.1]

Hi amazing community.

I am working with the following mcu STm32F103

Since in the design of our board we didn't insert any real eeprom for saving some data we decided 

to use a emulation tecnique   provided from ST 

Here below it is reported the header file

/**
******************************************************************************
* @file EEPROM_Emulation/inc/eeprom.h
* @author MCD Application Team
* @version V3.1.0
* @date 07/27/2009
* @brief This file contains all the functions prototypes for the EEPROM
* emulation firmware library.
******************************************************************************

We decided to save 50 kbyte of data for a log.. 

The question is the following. 

Do you have an idea about how many times we can write data in the flash ? 

Is there a maximun numer ? 

If yes can you provide this number or tell me where to find it ? 

Thanks a lot 

[Danish1]

---

We decided to save 50 kbyte of data for a log.. 

The question is the following. 

Do you have an idea about how many times we can write data in the flash ? 

Is there a maximun numer ? 

If yes can you provide this number or tell me where to find it ? 

---

The information is in the Data Sheet:

Section 5 "Electrical Characteristics"

5.3 "Operating Conditions"

5.3.9 "Memory Characteristics"

For stm32f103 the FLASH is guaranteed to work for 10000 cycles of write then erase.

Which (for many uses) is not enough. The STM32 eeprom-emulation is designed to emulate a small number of EEPROM memory-locations / addresses, and to allow you to update the values in those addresses randomly, multiple times. It does this by having at least two pages of FLASH, then every time you write it adds a new record of "address, value" onto the end of the already-written FLASH. When you come to read an address, it looks for the final record with that address. This way many single-word EEPROM writes are emulated over a larger area of FLASH, so individual FLASH cells are not cycled as many times

[SGasp.1]

Hi @Danish1 ..  thanks for you reply.. I understand that it was designed to emulate a small number of eeprom memory-locations and i see from the code that it has 2 pages (1kbyte each) for hosting the data. 

Considering this i need to save a log made of 50 kbyte. are you saying that is impossible with the stm32 eeprom-emulation or it is better to use a real eeprom ? 

Thanks a lot for your help

[Tesla DeLorean]

The EEPROM emulation has a lot of overhead and metadata. If you're looking to write large blocks of linear data, you're best just learning how to use the FLASH directly. Then your capacity is constrained by the memory available in the device you've chosen, and how much other code you need to generate, harvest and manage the 50KB. The F1 at least has relatively small pages/sectors.

Could use a real EEPROM, although I'd probably be tempted to use QSPI NOR Flash, and journal across that, or just write as files to a MicroSD or eMMC device

[Peter BENSCH · Accepted solution]

As mentioned by @Danish1 the resulting number of write cycles is calculated by multiplying the number of times the EEPROM is mirrored in the flash by the number of guaranteed flash write cycles of the STM32 (10k over the temperature range).

Let's assume you have an STM32F103, XL-Density (STM32F103xF or STM32F103xG) with 512 blocks of 2KB each = 1MB. If you want to achieve 100k write cycles, for example, you would have to store your 50K data area ten times, which would also take up 10x50KB = 500KB flash, which you may then be missing in the programme area.

You can see from this example that a large number of write cycles would require a lot of flash, which is why the EEPROM size to be emulated is usually made as small as possible. It is simply a calculation example of whether an external EEPROM is more favourable than the necessary on-chip flash.

[SGasp.1]

Hi @Tesla DeLorean thanks for your reply.. The idea is not to change the hw as first approach. 

So I agree with you that use the flash directly is a good idea. 

Just for my understanding how much is the overhead and metadata for the eeprom emulation. 

If i need to save one word how much is the over head ?

Thanks again

[SGasp.1]

Hi @Peter BENSCH thanks for your computation. So which is your best advise for storing 50kb (max) of data for the log. For sure not using the emulation . is it better to write directly in the flash or it is better to use an external memory. The 50 kB  is the max size of the log. each time we have to store 8 or 10 bytes . 

[Tesla DeLorean]

I haven't dug into the EEPROM Emu recently, but it was storing Address/Value type pairs when I looked at it, and was not compacting/combining.

The source is available, and I'm sure you could walk the generated memory images to recover the content and gauge the efficiency. Personally I think that time would be better applied to looking at how flash works in a more normative sense, and how that fits with the paradigm you're trying to solve. 

[SGasp.1]

Hi @Tesla DeLorean  makes sense to write directly the flash without using the eeprom emu.

But if i need to check how to change page / sector because the size of one page is limited. 

Thanks a lot 

[Tesla DeLorean]

One the F1 you can write to singular bytes once per erase cycle. The erase blocks are 512, 1024, or 2048 bytes as I recall depending on the model. Seem to recall a maximum of 256 sectors/pages being the limit, depending on die, or some smaller subset of that. There should be a #define for PAGE_SIZE or something similar. Then you'd need to deal with that alignment for blocks you wish to write/erase.