cancel
Showing results for 
Search instead for 
Did you mean: 

X-CUBE-EEPROM- Help calculating the required size of flash memory

EricNava
Associate II

Hi

I am am trying to use the X-CUBE-EEPROM package in my application.
I found this very helpful post which I am using as a guide to setup the code.
https://community.st.com/t5/stm32-mcus/porting-and-using-x-cube-eeprom-with-any-stm32/ta-p/570539

I think I need to define the flash address where the emulated eeprom starts.
In order to do that, I need to know the size of the emulated eeprom.

Formula
Application note an4894 gives a formula to calculate the required size of flash memory, but I want to make sure I am using it properly. Also note, I am using a STM32G070CB, which has a flash memory endurance of 1K cycles. This is less than the standard 10K of most other STM32 MCUs.

Here is the formula:

EricNava_0-1735920291724.png

Here is my calculation, I would appreciate if anyone can confirm I am doing it correctly!

I want to store a max of 50, 32 bit variables.
The page size of the STM32G0 series is 2KB.
The flash memory endurance is 1K cycles.

Variable elements per page = 500 = 2000 byte page size / 4 bytes for each variable
Number of EEPROM variables = 50
Number of cycles = 10000 (more on this later)
Flash memory endurance = 1000
Number of guard pages = 0
Page size = 2000 (2KB page size)

I get a result of 40KB from the formula.
That seems very high to store 200 bytes of data, so I don't know if i'm doing somthing wrong.
If I am doing things correct, I guess it is so high becuase I am trying to get 10K cycle endurance with 1K cycle endurance flash.
If I modify my requirements to only be 1K cycles, I get a result of 4KB.
4KB seems much more reasonable, however another issue arrises if I want to set 1K cycles in eeprom_emul_conf.h.

Software
In X-CUBE-EEPROM, eeprom_emul_conf.h, the cycle define is this:

 

#define CYCLES_NUMBER           1U   /*!< Number of 10Kcycles requested, minimum 1 for 10Kcycles (default),
                                        for instance 10 to reach 100Kcycles. This factor will increase
                                        pages number */

 

Since  CYCLES_NUMBER is in increments of 10K cycles, it doesn't seem possble to allow 1K cycles like I want to reduce the flash needed. I don't think I can put 0.1 for CYCLES_NUMBER right?
If I just set CYCLES_NUMBER to 1, will the eeprom use 4KB or 40KB, becuase I can't see anywhere in the code where the flash endurance of the MCU is defined?
Perhaps I am missing somthing?

Any help is greatly appreciated!

 

7 REPLIES 7

The implementation is quite wasteful, carrying a lot of metadata with it.

If you need to write a sizeable block/structure of data you'd perhaps do a lot better just journalling that over a pair of FLASH pages

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

@EricNava wrote:

Page size = 2000 (2KB page size)


Are you sure that's not 2048 ?

I was a bit confused by that actually, but I think you are right.
The reference manual says 2K, but the number of addresses per page is 2048.

EricNava_0-1735998713412.png

 

For sure it seems quite wasteful, but I like it handles a lot of error checking and stuff for me.
I guess my main question now is the CYCLES_NUMBER definition. It seems to me like ST wrote the code assuming all MCUs would have multiples of 10K endurance, but the STM32G0 doesn't. It is officially supported though, and in their example for the STM32G0 they set CYCLES_NUMBER to 1. When set to 1, I guess the actual endurance will be 1K cycles.

You can play with the scale here

eeprom_emul.h

#define PAGES_NUMBER \
(((((NB_OF_VARIABLES + NB_MAX_ELEMENTS_BY_PAGE) / NB_MAX_ELEMENTS_BY_PAGE) * 2U) * CYCLES_NUMBER) + GUARD_PAGES_NUMBER)

Some of the limitation is related to the Charge Pump and High Voltage lifespan

You've got some STM32 parts where if you limit interaction to a handful of pages the cycle count can get very high. I'll see if I can find a citation, but perhaps F7 or H7, but these have very large page sizes, not the nice small and uniform ones.

The biggest problem with the library implementation, as I see it, is that it's made very general, with virualized byte and address space. If you have a more narrow definition of what it needs to save, and how frequently, you could probably create something with a longer lifespan and more robustness.

You need at least two pages to allow all the information to be collected in one, and be able to erase the most stale/redundant data so it can keep looping.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

@Tesla DeLorean wrote:

If you have a more narrow definition of what it needs to save, and how frequently, you could probably create something with a longer lifespan and more robustness.


Indeed - this is exactly what I have done.