I’m trying to record the state of relays through power loss (which is usually unplanned) and reset. As a result anytime the state of a relay is changed, it is also written to EEPROM and fetched in setup(). Does this negatively impact the EEPROM or anything like that if the relay states are changed frequently? Is there a better way to accomplish state retention during power loss/reset?
@DriftingShadows, assuming you are referring to a Particle device, the EEPROM is actually emulated with flash memory. Flash has a limited write cycle lifetime vs real EEPROM. Luckily, some clever wear-levelling code is used by Particle to extend the life of the flash memory used. However, how often are you expecting to change relay states?
@peekay123 Yep sorry, more specifically I was referring to the Photons. They’re being used in a heating scenario where relays will be toggled as temperature goes above a set temperature and dips below. I havn’t tested in production environments unfortunately, but at a guess worst case I’ll say 100 times per day.
@DriftingShadows, How many bytes would you be writing to the EEPROM on each write?
@peekay123 The relay state would either be a 1 or 0. So 4 bytes for int? Or would changing it to 1 byte be better.
@DriftingShadows, So worst case for you looks something like (@peekay123 correct me if I’m wrong) :
Assuming flash MTBF is about 100k writes…
2047 bytes of flash / 4 bytes per write = 500 writes (to fill the EEPROM)
100k max writes to each flash byte * 500 writes to fill EEPROM = 50M writes till flash fails.
50M / 100 max writes per day = 500,000 days = 1369 years until flash fails.
Is this assuming I havn't used any other of the EEPROM's memory? Additionally, according to your calculations if I change the writes to 1 byte instead of 4 it'll improve the life span too?
Just wanted to mention it might be worthwhile looking into retained variables using a small button cell battery.
@DriftingShadows, yes, you are correct that I was only using 4 bytes because that was your estimated storage usage. If you write more than 4 bytes, or write more often than 100 times/day, then the usable life will be less. However, even at 10 times the usage, the lifespan is over 136 years. I don’t think the hardware will last that long… but then again, there are no electrolytic caps on the Photon which, in my experience, have blown on some ancient servers I used to work on (otherwise they may have run forever.)
I am working on a similar project where I want to track relay state even after power outage. In my case, I am going to use an external FRAM because the wear life is 1M+ writes (10 times more than most EEPROM.) Or as @Moors7 suggested, check out Backup RAM. Backup RAM shouldn’t suffer from wear but it does require a battery on VBAT to retain variables between power outages. You can use a small CR2032 or similar battery.
1 Like
As @ninjatill points out, the wear leveling algorithm in the DeviceOS ensures the emulated EEPROM will last well beyond your product’s lifetime in your case. Nonetheless, @ninjatill does a great job of explaining your different options. Note that FRAM is available in both I2C and SPI versions and some folks have used a rechargeable CR2032 battery to power the retained RAM (and RTC) in the Photon during power loss. However, with proper hardware design and good exception handling in your code, the emulated EEPROM method is a good approach.
3 Likes
Question: Is the 100K MTBF for flash failure based on writing sectors or individual bytes? If sectors, how big are the sectors in this design? Also if sectors, does the wear leveling algorithm take this into account?
I do not have all the details for wear leveling. My calcs were rather crude and just assumed bytes.
IIRC there are two sectors/pages (one 16K and another somewhat bigger one) and the 2K EEPROM space is relocated across these pages till the availabe free cells are exhausted which then leads to a page switch and erasure of the full page.
Consequently you can expect a lot more rewrite cycles than you’d expect with flash otherwise.
But if you want to know more, there are already some threads in this forum that explain it in more detail.
1 Like
Thanks everyone for the help!
2 Likes