No EEPROM, what to do?

[RMyer.1]

Hi All,

I'm using a STM32F030x4 that has no EEPROM but I don't want to implement EEPROM emulation on the Main Flash as I only need to 'save' a couple of bytes during power off.

Is it possible to use the 'User data option byte' @ 0x1FFF_F804 as a non-volatile memory store location?

I've read the datasheet but I am still not sure if this User Option byte can (or should) be used in such a way.

Thanks.

[S.Ma]

Well if an external I2C eeprom of 128 bytes is out of reach, check if you have a free flash sector. Option byte is a system flash area, watch out. Eeprom emulation is to erase a sector and fill it up with user data. Ideally dual sector to speed up and avoid the sector erase wait time which expose the device to a power down, removed battery while erasing... also think cycling, how many times the eeprom emulated will be written.

In other word, estimate your acceptable end customer field return.

If using an external EEPROM search for F-RAM, it can be very useful to know the differences in performance and durability.

What is FRAM?

FRAM, an acronym for ferroelectric random access memory, is a non-volatile memory that can hold data even after it is powered off. In spite of the name, FRAM is a ferroelectric memory and is not affected by magnetic fields as there is no ferrous material (iron) in the chip. Ferroelectric materials switch polarity in an electric field, but are not affected by magnetic fields.

What are FRAM’s key advantages over Flash/EEPROM?

1. Speed. FRAM has fast write times. Beyond all the other operations, the actual write time to an FRAM memory cell is less than 50ns. That is up to 1000x faster than Flash/EEPROM. Additionally, unlike EEPROM where you must have two steps to write data: a write command, followed by a read/verify command; FRAM’s write memory function happens in the same process as read memory. There is only one memory access command, one step for either reading or writing. So in effect, all the time associated with an EEPROM write transaction is eliminated in an FRAM-based smart IC.

2. Low Power. Writes to the FRAM cell occur at low voltage and very little current is needed to change the data. With Flash, high voltages are needed. FRAM uses very low power – 1.5v compared to 10-14v for Flash. FRAM’s low voltage translates into low power usage and enables more functionality at faster transactions speeds.

3. Data Reliability. Because only a small amount of energy is required, all the necessary power for FRAM is frontloaded at the beginning of data write. This avoids “data-tearing,�? a partial write of the data which occurs when Flash based MCUs are removed from the power source during a write cycle. Further, FRAM experiences 100 Trillion read/write cycles or greater – far exceeding Flash or EEPROM write cycles.

4. Unified memory means it’s the only technology to eliminate boundaries between variable and constant data, which simplifies data handling, in-system programming and firmware image 

https://www.ti.com/lit/wp/slat151/slat151.pdf

[waclawek.jan]

> Is it possible to use the 'User data option byte' @ 0x1FFF_F804 as a non-volatile memory store location?

Yes.

But it's literally a couple of, i.e. two bytes.

And you have to perform an erase/program cycle, which is subject to the same restriction as erase/program in FLASH, i.e. you cannot execute code from FLASH while erasing/programming. While DS does not specify exactly erase/program time for option bytes, I'd wager a bet that it's the same as erasing a page in FLASH and programming 16 bits, i.e. max.40ms/60us.

Also, endurance limit applies, most probably the same as for FLASH (i.e. 10k).

JW

[RMyer.1]

Thank you all for your responses.

I have plenty of spare flash space to implement a system to store the byte I need to keep and probably never run out of space before a page would need to be erased to start over again.

The byte is probably only ever going to be changed 100 times if that so even a 'dirty' fix like using the 'User data option byte' might still be feasible as erase/write cycles shouldn't be an issue.

This is not a commercial product, just me messing around at home.

I appreciate that ST do have some STM32 devices with EEPROM in them but finding them already on a dev board (at the moment at least) is very hard.

[Pavel A.]

> I appreciate that ST do have some STM32 devices with EEPROM in them

They actually do. Some L models have real EEPROM. Some STM8 have real EEPROM as well.

[Sebastiaan]

Still not sure why you don't want to use eeprom-in-flash emulation. That works pretty nicely, and it doesn't matter if it's just about 2 bytes or a bit more (as long as you're not talking about kilobytes). Doesn't look like a valid reason to NOT use it IMO :)