EEPROM emulation: working principle

[filogold]

Hello everyone,

I'm currently working on an STM32L433 microcontroller and, considering cost and space-saving aspects, I opted to implement an EEPROM emulation library. While I've been going through the related documents, I've encountered a few uncertainties about its functionality.

Initially, I intended to store a 32-byte string and conducted some tests on an F4 Nucleo board using the STM-provided test code files. However, the method I observed for saving the string into memory seemed weird. It required dividing the string into 32 parts and storing them sequentially, leading to 32 memory erase operation. This approach appears highly inefficient. (I'd like to mention that I plan to perform this operation a maximum of 20 times a day. However, if my understanding is correct, I could simplify this process by utilizing 3 integer variables instead of 32, compressing the useful information.)

Upon examining the library's structure for "L4" MCU, similar to the case with the "F4" Nucleo board, it seems the library only supports storage for 32-bit variables. I'm unsure if this limitation stems from how the memory is constructed, or if I'm overlooking something crucial.
It's puzzling because, if this were the only method available to store information and code, flashing code into the memory would result in a high number of erase operation each time, which seems impractical.

My other doubt are regarding the AN4894 application note. In particular:
"The first set of pages is initially erased and used to store new data, with flash memory programming operations executed sequentially in increasing order of flash memory addresses. Once the first set of pages is full of data, it needs to be garbage-collected. The second set of pages collects only the valid data from the first set of pages, leaving the remaining area available for new data storage. Once the transfer of valid data to the second set of pages is completed, the first set of pages can be erased."

I'm confused about how this procedure reduces memory stress caused by erase operation. If I save my data in the first page and then move it to the second, it appears that I'll need to erase the memory twice as often. Additionally, I'm unclear about the meaning of "garbage-collected" – if I'm saving data into memory, it implies that I intend to retain it.

Apologies for these queries, but I'm striving to comprehend how this process functions without results.

[TDK]

The entire flash page is filled up before it is erased. Portions of it are marked as dirty/obsolete and get cleaned up when the page finally gets erased.

You should be able to break up your string into 32-bit chunks and save those separately, then re-assemble them when reading.

[Chloe Meunier]

Hello,
The EEPROM emulation library provided by STMicroelectronics divides the flash memory into 2-kilobyte pages, with each page being divided into multiple 32-bit blocks. Data is stored in these 32-bit blocks, with each block being associated with a unique address.

When new data needs to be written, the EEPROM emulation library writes the data to the first available flash memory page. Once the first page is full, the library performs a garbage collection operation to move valid data to a second page, leaving the first page available for new data. This garbage collection operation involves copying valid data from the first page to the second page, compacting it to minimize free space. Once all valid data has been copied, the first page is erased and ready to be reused.

Using flash memory to store long-term data can put additional stress on the flash memory, as erase operations are necessary to free up space but the EEPROM emulation library minimizes this stress by performing garbage collection operations to compact valid data and minimize free space. The library allows users to specify the maximum number of write operations before a garbage collection operation is performed, allowing for control over the number of erase operations needed.

You should look in detail at the operating diagrams of AN4894 to understand the storage principle

BR

Chloé

 

[MM..1]

Primary you miss  

---

@filogold wrote:

 

..., leading to 32 memory erase operation.

---

memory is filled up by write only operation . And for more effective you can write own system, but i mean example emulation with little user logic is ok.

[Tesla DeLorean]

It should be journalling across two pages so as to reduce the wear and increase the robustness. It should only erase one of the pages once both pages are consumed, and it should likely collect all the data and consolidate for "garbage removal"

If you can possibly understand the FLASH methods, just use those directly, and a structure of your own that you can manage and journal across a couple of pages.

The EEPROM Emulation is really for the intellectually lazy who don't want to change their operating paradigm to fit the features and functions of the MCU they've ported legacy code too. The emulation doesn't really replace a larger randomly addressable EEPROM