EEPROM

I have few bytes(around 20) to store in EEPROM. I have seen example of EEPROM emulation, which seems awesome. But I have some questions.

• Is it safe to use ? will it reduce life of uC ?
  Is there any disadvantage of it ?
  Will it still work if I enable read-protection of the uC’s flash ?

For sure it will reduce the uC life time if you write very often. (With bad programming you can ruin it within minutes)
See ST application note page 5/10 (Write/Erase cycles)
http://www.st.com/content/ccc/resource/ … 165693.pdf

There is also another small storage area, but I cant remember whether it keeps the data after a power cycle or how big it is.

If STM Flash endurance is an issue, why not simply use I2C EEPROM, they are cheap on eBay, even for large ones.

martinayotte wrote:If STM Flash endurance is an issue, why not simply use I2C EEPROM, they are cheap on eBay, even for large ones.

I thought the endurance was > 10000 erase cycles.

Also each 1k flash page is separate, so its at leas 10,000 times the number of pages.

But if you want to use different flash pages, you’ll need to write code to manage how many times you use each page of flash e.g. store a usage count in that page with your data.

The RTC also has some battery backed up registers (80 bytes, so far as I recal)… but you obviously need a battery attached to keep them after power off. Fine if you are planning on using the RTC in your project, since you would be fitting the battery anyway.

http://www.st.com/content/ccc/resource/ … 025071.pdf

Section 1.9

Thanks Andy. I think that was the data storage area I remembered.

It survives a reset, as well, as long as you keep the normal power on.

Thank you all, I think I should avoid emulated EEPROM.

martinayotte wrote:If STM Flash endurance is an issue, why not simply use I2C EEPROM, they are cheap on eBay, even for large ones.

…for the W25Qxxx I adapted a driver/library in the past –> viewtopic.php?f=13&t=9
They are ultra cheap I soldered the plain chips myself with a smd-adapter board. Drawback: You must delete a whole sector (16 pages) before overwriting, so you need a least a 4kb buffer (for the page) or using a buffer sector on the chip (reading the overwriting sector out, pushing it to the buffer sector and write the differences to the overwriting sector).

I see there is a newer library for arduino out: https://forum.arduino.cc/index.php?topic=324009.0
Haven’t looked inside, but I assume that converting it is simple (only SPI routines)

ahull wrote:The RTC also has some battery backed up registers (80 bytes, so far as I recal)… but you obviously need a battery attached to keep them after power off. Fine if you are planning on using the RTC in your project, since you would be fitting the battery anyway.

http://www.st.com/content/ccc/resource/ … 025071.pdf

Section 1.9

simonf wrote:ahull wrote:The RTC also has some battery backed up registers (80 bytes, so far as I recal)… but you obviously need a battery attached to keep them after power off. Fine if you are planning on using the RTC in your project, since you would be fitting the battery anyway.

http://www.st.com/content/ccc/resource/ … 025071.pdf

Section 1.9

I never got round to testing whether the STM32F103C8XX *actually* has the full 84 bytes, in the same way that it has 128k flash, I suspect not.
The CB is a medium density as well so it’s not rated for the 84 bytes too..
Anyway who knows that both C8 and CB are in truth high density devices..

edogaldo wrote:I never got round to testing whether the STM32F103C8XX *actually* has the full 84 bytes, in the same way that it has 128k flash, I suspect not.
The CB is a medium density as well so it’s not rated for the 84 bytes too..
Anyway who knows that both C8 and CB are in truth high density devices..

IMO,
FRAM makes more sense.

I have some samples but I have never gotten around to a lab test. Retirement is a busy phase of life.

Ray

Ohh, glad i read this page.

See i thought there wouldnt be any issue with regularly saving data.

In my speedo project theres going to be a configuration page on the display. here you can set some of the global variables. I assumed that the variables would be stored on the flash.

Also the odometer, while thats just counting the miles. Thats a variable thats going to be regularly updated and stored.

So from reading this thread, storing in eeprom or the onboard flash is a really bad idea…

Whats a better alternative?

Nutsy wrote:
So from reading this thread, storing in eeprom or the onboard flash is a really bad idea…

Whats a better alternative?

In addition to what Andy has said

Storing settings in Flash is fine, as I suspect they don’t get updated that often

Writing the ODO data to flash e.g. with a value to 0.1 mile, means you will be updating this quite often, several times a minute, so you would need to employ a strategy where you were not constantly having to erase the flash

You’d need to check the manual, but I thought that its the number of erase cycles thats limited.
So you could just, for example, use a 2x 1k banks of flash, and initially erase the active bank, then write the data into locations sequenitally, without erasing the whole bank each time.

In this scenario, at powerup, you could would need to scan down from the top of both banks, to find the first address that was not blank, and read that value as the ODO value, then on the next update, of the ODO data your code would write to the next address, above the address where it found the data.

When you reach the end of one bank of ram, you would need to put data into the first location in the next bank, and then erase the current bank, ready for reuse.

So that your 2 banks of flash perform a circular store

Or, as Ray said, you can use FRAM, although more expensive :

– High-endurance 100 trillion (10^14 ) read/writes

martinayotte wrote:Or, as Ray said, you can use FRAM, although more expensive :

– High-endurance 100 trillion (10^14 ) read/writes

Or MRAMs, unlimited endurance (Everspin.com)

Some TI MCU have Fram and there are also some Launchpad boards. I have one of them with Fram and a supercap but I used only with the datalogger example.

FRAM doesn’t need supercap, so it must be needed for some RTC.

For those interested, since the SPI FRAM are pretty expensive, I search and found some I2C FRAM well cheaper on eBay : FM24C256

martinayotte wrote:For those interested, since the SPI FRAM are pretty expensive, I search and found some I2C FRAM well cheaper on eBay : FM24C256

FRAM is nice, but I doubt its really necessary. Clever use of the Flash would almost certainly be able to do this with a long enough lifespan.

If the OP could sense when the power is going off, and then have time to save the value to flash, that would be one option e.g have a capacitor large enough to keep the CPU running for a millisecond should be enough, assuming the flash bank is already erased and ready to be programmed.

RogerClark wrote:FRAM is nice, but I doubt its really necessary. Clever use of the Flash would almost certainly be able to do this with a long enough lifespan.

If the OP could sense when the power is going off, and then have time to save the value to flash, that would be one option e.g have a capacitor large enough to keep the CPU running for a millisecond should be enough, assuming the flash bank is already erased and ready to be programmed.

Or add a small battery to maintain the VNRAM

We can use the EEPROM from DS3231 RTC through the Wire library:

DS3231 STM32F103ZET6
VCC 3.3V
GND GND
SDA PB7 (i2C1_SDA)
SCL PB6 (i2C1_SCL)

madias wrote:

I see there is a newer library for arduino out: https://forum.arduino.cc/index.php?topic=324009.0
Haven’t looked inside, but I assume that converting it is simple (only SPI routines)