EEPROM emulator

General
1

Documentation Quote:
The EEPROM emulator allocates a region of the device’s built-in flash memory to act as EEPROM. Unlike “true” EEPROM, flash doesn’t suffer from write “wear” with each write to each individual address. Instead, the page suffers wear when it is filled. Each write will add more data to the page until it is full, causing a page erase.

Sorry, but I don’t understand this “page erase” thing.

For example: if I EEPROM.write(6, 126); two thousand times ( or 9 trillion times), will that cause a page erase?

2

google the way flash works, you’ll see that it can only erase a page at a time, unlike eeprom that can (usually) work at the byte level.

1 Like
3

Ok, thanks for the info. But does that mean that my saved data will be transferred to a new page, and I don’t really need to worry about its inner workings, or will my stored data just disappear ?

4

it’d be a pretty poor emulation of eeprom if it ate your data.

It should not eat your data.

2 Likes
5

Thanks @AndyW for the info. When I read the documentation on EEPROM, I started to worry.
So, my saved data will be accessible by the addressing, and I really don’t care what page it is on at the moment…

6

All data can be accessed as long as people know where to find it. That’s not an EEPROM issue at all.

You need encryption or self-defined values that only your program can decipher if that’s a concern.

FLASH areas on the Photon are locked and probing on the surface in general will not reveal too much info.

7

So, does that mean if I use:

EEPROM.write(6, 126); // 9 trillion times
Then later, maybe months/years
value = EEPROM.read(6);

I will get my "126" back ?

8

Your data will probably be corrupted an exceeded the write cycle for 9 trillion times. :wink:

There’s a stated guarantee for data retention for STM32 ICs if i am not wrong and you can read that up :slight_smile:

9

You would get “126” back because the library is smart enough to know that it doesn’t need to write the value if it is the same as the value already stored. If you wrote different data to the same location, you might wear out the underlying FLASH RAM used to emulate an EEPROM, but it is hard to calculate since it is page erases that count for wear and the library does wear leveling using the algorithm that ST Micro, the processor manufacturer, recommends. It is actually data dependent since the FLASH is erased to all 1’s and can only be written to zeros and the library knows this and is clever.

It would take at least 100 days of continuous writing to get to 9 trillion writes, by the way.

Can we please be done being silly here?

2 Likes
10

Ok, I think I see. There is still some write wear, and 9 trillion writes would probably be to much.
But if that was reduced to about 5 million, it should work fine? Maybe even 2 billion?
Is there a time delay during writing? Does it block other user code from running?

BTW: I wasn’t trying to be silly, just give an example that was not ambiguous. If I had said 2 billion, that would have been borderline I thought. Sorry