EEPROM.put - where does it stores data?

[mrburnette]

Each STM32 "core" runs a set of datacentric variables within the Arduino IDE environment; these variables are read at compile time to allow build scripts to know how to manipulate things that change between different microcontroller models. So an STM32F103 uC will have different environmentals that an STM32F4xx.

To make it more complicated, the STM32Duino "Official" core and the Roger's core use different scripts. So, it is possible that a EEPROM library for Roger's core will not work as expected with the Official core.

Each core will have libraries that should be used with only that core. Of course, anything can be hacked to persuade it to work, but you are going to have to go through the effort yourself of find someone online that has already done this work.
Example:

https://github.com/rogerclarkmelbourne/ ... ies/EEPROM

https://github.com/stm32duino/Arduino_C ... ies/EEPROM

IMHO, the very best way to deal with this EEPROM needs is to use a real EEPROM chip. These chips are often found on precision clock modules. Like for example: (not a vendor recommendation)

https://pmdway.com/products/precision-d ... rom-module

Of course, if you do not need the clock, just buy the external EEPROM. If you are going to cycle the data often, consider FRAM. I know at least one member of Roger's forum that successfully made FRAM work:

[kvv213]

According to the credentials at h-file of my EEPROM (taken from Duino package) it is:

EEPROM.h - EEPROM library
Original Copyright (c) 2006 David A. Mellis. All right reserved.
New version by Christopher Andrews 2015.

It utilizes EERef class and it works with STM32F103 Flash chip I don't know how but it works, so it seems that it can do this thing.

The size of memory that is reserved for RAM and for Flash are defined in the chip linker script:

RAM (xrw) : ORIGIN = 0x20000000, LENGTH = LD_MAX_DATA_SIZE
FLASH (rx) : ORIGIN = 0x8000000 + LD_FLASH_OFFSET, LENGTH = LD_MAX_SIZE - LD_FLASH_OFFSET

That is plenty of space. And I use it for storing of my settings (just 1-2 kb) - ready every boot, save at configuration state. And it is not wise to not use of this memory.
But, as it was previously mentioned - the system uses the last page for flash write access. The page can be wrongly located too far to RAM space thus addressing of a little bit larger settings chunk can lead to some RAM violation.

To date I've reduced the amount of stored settings so the problem gone but it seems it can return in someday.

PS. I have EEPROM chip at my board connected via I2C. But actually it works not so fast and used for storing necessary online values that require to be overwritten often.
PSS. Under the standard STM32Duino lib I understand this one https://github.com/stm32duino/Arduino_C ... c/EEPROM.h

[mrburnette]

...
To date I've reduced the amount of stored settings so the problem gone but it seems it can return in someday.

PS. I have EEPROM chip at my board connected via I2C. But actually it works not so fast and used for storing necessary online values that require to be overwritten often.
PSS. Under the standard STM32Duino lib I understand this one https://github.com/stm32duino/Arduino_C ... c/EEPROM.h

Perhaps Frederic can provide some imput beyound what is in the thread so far. I have no recommendations.

As for the external I2C EEPROM, you may want to do a quick read here and determine if anything of value exists.
https://forum.arduino.cc/index.php?topi ... msg3072940

[Phono]

Hi all,
I am porting a set of projects initially written under Roger's core to STM32Duino. I am at the point of porting the EEPROM emulation part that I use to store configuration. It changes about twice a day.
I am bothered with what I read in the STM32Duino wiki.
In Roger's core, the EEPROM emulation library I used, each time you overwrite a cell, just obliterates that cell and creates a new one with the same index. It is only when the Flash page is exhausted that its contents are copied to the other page and the current page is erased for future use.
This seems a reasonable way since each cell is only written twice until a page is full, which spares the flash memory life.
I have read the wiki, and I find this alarming statement:

EEPROM emulation
EEPROM emulation is based on Arduino API: https://www.arduino.cc/en/Reference/EEPROM
Emulation is made in Flash, with all constraints related to Flash operation:

whole sector/page erased and written for each write operation.
Can be very long depending on sector/page size
limited Flash life cycle write operation
In addition to Arduino API, to mitigate Flash constraints, it is possible to use buffered API:
Write operations are made in an intermediate RAM buffer, and only at the end (after writing several parameters for example) the buffer is copied in Flash. Thus only 1 write operation for a whole bunch of data.

So according to this text, the whole flash memory page is erased and written once for each byte written! I cannot believe this. They mention it is possible to reduce the memory wear by using the buffering mechanism that the library provides.
So what is the truth? As far as i understand there is no need to erase a whole page to write a single byte.

[fredbox]

See https://www.st.com/content/ccc/resource ... 165693.pdf

[mrburnette]

...
I am porting a set of projects initially written under Roger's core to STM32Duino. I am at the point of porting the EEPROM emulation part that I use to store configuration. It changes about twice a day.
...

There is not just a single scheme used to enable user variable storage. However, fredbox provided the PDF reference from STM. For readers that simply will not take the time to download and read same, I extracting the key takeaway:

The main differences between embedded Flash memory and external serial EEPROM are
generic to any microcontroller that use the same Flash memory technology (it is not specific
to the STM32F10xxx family products).

One of the major differences between external EEPROM and emulated EEPROM for
embedded applications is the writing method.
● Standalone external EEPROM: once started by the CPU, the writing of a word cannot
be interrupted by a CPU reset. Only supply failure will interrupt the write process, so
properly sizing the decoupling capacitors can secure the complete writing process
inside a standalone EEPROM.
● Emulated EEPROM using an embedded Flash memory: once started by the CPU, the
write process can be interrupted by a power failure and by a CPU reset. This difference
should be analyzed by system designers to understand the possible impact(s) on their
applications and to determine a proper handling method.

The software and implementation described in this document use two Flash memory pages
to emulate EEPROM.
Each variable element is defined by a virtual address and a value to be stored in Flash
memory for subsequent retrieval or update (in the implemented software both virtual
address and data are 16 bits long). When data is modified, the modified data associated
with the earlier virtual address is stored into a new Flash memory location. Data retrieval
returns the modified data in the latest Flash memory location.

But remember, the above is just "a way" to implement. Any library author can implement an alternative methodology.

Ray

[fpiSTM]

For the STM32 core, this is not this "way" implemented in the STM32 core.
And yes whole page/sector is erase/write, that's why the eeprom buffer has been implemented to avoidtoo much access :
https://github.com/stm32duino/STM32Exam ... EEPROM.ino