Will this be the end of the stupid "eeprom emulation"?

[Pavel A.]

https://www.st.com/en/memories/m95p32-i.html

A huge 4 MB EEPROM on quad SPI... with ECC... Looks nice. But will it be available to buy?

[JPeac.1]

From the description this looks like one of those dual die packages with some leads bonded internally. Note it takes at least a dual SPI. these have been around for a while. Not higher density, just newer packaging.

And yes, I hope ST will finally put to rest the headaches of pretending part of the code flash is an EEPROM through some supposed software magic. Go with an I2C or SPI part and save yourself the misery of trying to get emulated EEPROM to work.

[Pavel A.]

>Note it takes at least a dual SPI.

?? Where is this mentioned? The SPI diagrams in the DS show that data reads can be single to quad; writes and all other commands are single-line?

However, the programming model of this does not look quite like a 'normal' eeprom. To change any byte within a non-erased 512-byte page, the whole page is erased and rewritten. This can cause whole page loss if power-off or a reset glitch hits in the middle. It looks more like a QSPI flash with very fast erase.

[Peter BENSCH]

@Community member​ Yes, there are currently manufacturers who are already stacking 192 of their flash dies on top of each other, but they are in a completely different quantity and price range.

Do you seriously think we can squeeze two dies into a UFDFPN8 with a minimum 0.4mm package for that price?

BTW: what does Dual-SPI have to do with two dies in one housing?

@Pavel A.​ Yes, this EEPROM will be available for purchase. However, the component was only launched a few months ago, so a little patience is needed.

Regards

/Peter

[Piranha · Accepted solution]

Regarding the topic title there are three levels of that discussion.

First, you probably mean HAL/Cube team's implementation of EEPROM emulation. Obviously that is a broken bloatware, because everything done by that team is like that.

Second, emulating an EEPROM in many cases is just a stupid design. Most of the projects use it for storing user configuration. But think about it. On hardware side you have an MCU's internal FLASH memory with it's features and peculiarities. On software side you have a requirement to store the user configuration, which consists of a variables of a different and probably even varying size. Why on earth would you want to store that data in something that emulates a hardware EEPROM with a different set of features and peculiarities than your actual hardware memory? The most obvious of those limitations is the fact that EEPROM is an array of a constant sized elements with a size up to 4 bytes. Why emulate that, when you can develop something more flexible and better fitted to the task?

Third, a properly designed configuration storage system has some advantages over external memories:

1. The board can use less components, MCU pins, board space and cost less.
2. With readout protection on MCU, the configuration cannot be read or written by external tools.
3. Accesses to internal memory can be faster than accesses to external memories.

[heveskar]

Hi,

could you please elaborate on the second point, what paradigm to use when storing user information to flash is wanted? I have found in various places on this forum that EEPROM emulation is really stupid and ineffective (especially on STM32H7 which we are using), but nowhere is it mentioned how to properly do it (except using external EEPROM, which we will probably have to use in the end as the emulation is really unreliable for us).

[Pavel A.]

Advises were given in some of these threads. However, answer depends on the amount of data to keep and consistency requirement (i.e. is the whole set of data/parameters is considered "atomic" or some data elements are independent).

[S.Ma]

If the goal is to easily switch between real external eeprom to an internal emulated one with as little code change as possible, maybe. External eeprom means access time is not critical. Data protection using internal memory raises a bit its access difficulty (security is a difficulty scale). The write max cycles is one limitation, the erase-reprogram time being another, as true eeprom is max 5 msec. The unlucky one trying to write the emulated one when a sector erase is in progress and the mcu power being suddenly cut off will test such emulation ruggeddlness. Usually Customer Returns for faulty device requires non volatile memory for storing the number of power on reset, the on time for void warranty, tamper, etc.... these are more than just user config, and the need usually comes once your new product hit the field for the first time, and you are learning on the spot....

Didn't look at stm32 flash eeprom emulation.... is there hope to improve it from its current state?