I know from using the EEPROM as non-volatile storage on the Core that there was a stated limit to the number of times it could be written/overwritten.
I’d like to save a timer value across device reboots, but it’s a “just in case” thing, not a mission critical function. This timer value is updated quite often, so I don’t want to burn out my write “allowance” with it.
I have tried to read through related forum posts and the Photon datasheet, but I see no mention of any such write limitation for the Photon, and a mention that it is “emulated” EEPROM, which suggests to me that it would not have such hardware restrictions.
Does this mean that this limitation no longer exists on the Photon?
If it does, no problem - I saw great instructions on another post for how to add some non-volatile storage. I’m not storing much data, though, so an SD card via I2C or something is massive overkill if I can just use the Photon’s emulated EEPROM without worry of running out of write cycles.
The limitation still exists but if you only want to save the data across reboots without loss of power, you can just use the retained feature which saves variables in a battery backed SRAM area. If you additionally apply a coincell battery to VBAT you could even depower the Photon’s main core but the SRAM would still survive.
@Fabien, flash still suffers wear but on a page level instead of a byte level (read the section again). The emulated EEPROM uses wear leveling logic (in the system firmware) to reduce page wear but it is still there. I would still consider using the retained variable on the Photon as @ScruffR pointed out . By tying Vbat to 3V3, the retained RAM will be maintained as long as power is applied to the Photon. This applies through hard and soft resets, as well as, all sleep modes. Since the value is not mission critical, using retained variables is the best approach IMO.
My main concern is while I am developing the software backend for my project, frequent reflashing is resetting some key timer variables that I would like to keep intact.
@peekay123 Sounds like if there’s no drop in power supply across a firmware reflash, this will work perfectly to prevent that.
Are you saying I need to jump VBAT to 3V3 for this to take effect, or will simply adding the retained keyword suffice?
@patrickcentral, you will need to add the jumper. As for retained RAM values persisting across firmware updates, you’ll need to test it as I have not (at least not yet).
I think the minimum flash endurance from the data sheet is a minimum of 10,000 cycles. But the EEPROM code does wear leveling. If you’re writing say 4 bytes of data to virtual EEPROM, actually 8 bytes are written to flash. And the flash is 16K bytes so it takes 2048 writes before a page needs to be erased. And there are two pages. So you can do 4096 * 10000 writes and still be in the minimum flash life. If you wrote the four bytes to EEPROM once per minute it would take 78 years for it to wear out.
In my case this value is being overwritten whenever the loop isn’t doing something else, which can often be multiple times a second, so it would shorten the life considerably - though you’re right, it’s still probably going to last long enough to replace it with whatever new product is out by then.