EEPROM Write endurance optimization

Status
Not open for further replies.
Y

yeahtuna

Well-known member
About a year ago, I was poking around and I noticed this in eeprom.c

Code: 
// The EEPROM is really RAM with a hardware-based backup system to
// flash memory.  Selecting a smaller size EEPROM allows more wear
// leveling, for higher write endurance.  If you edit this file,
// set this to the smallest size your application can use.  Also,
// due to Freescale's implementation, writing 16 or 32 bit words
// (aligned to 2 or 4 byte boundaries) has twice the endurance
// compared to writing 8 bit bytes.

I often update data structures to EEPROM, and I'm concerned that I might be putting more wear on the EEPROM than I should be. Below is my code for writing a structure to EEPROM. Has anyone made something similar that takes into account the above suggestions to ensure optimal endurance? I notice EEPROM.h has a put function. Does that take the above recommendations into consideration?
Code: 
void writeBlock(char* data, int startPos, int size)
{
	for (int x = 0; x < size; x++) {
		EEPROM_write(startPos+ x, data[x]);
	}
}
 
I'd use the existing routine for writing blocks. Specifically:

void eeprom_write_block(const void *buf, void *addr, uint32_t len)
 
yeahtuna said:
I often update data structures to EEPROM, and I'm concerned that I might be putting more wear on the EEPROM than I should be. ]
Click to expand...
I don't have a good coding answer to your problem. I faced a similar problem because my application updates a large set of data structures once per second in permanent storage and has been doing so reliably for the last year. I dodged the wear levelling problem by using FRAM which is not subject to this problem and so far the results have been stellar.
This is the product I used but there are several variations available from many suppliers.
https://www.aliexpress.com/item/33010313163.html
This worked so well and was so easy to implement that I am always surprised that people choose a route subject to wear levelling problems. But who knows? I may still encounter a gotcha further down the road but so far it looks good.
 
PDOS said:
I don't have a good coding answer to your problem. I faced a similar problem because my application updates a large set of data structures once per second in permanent storage and has been doing so reliably for the last year. I dodged the wear levelling problem by using FRAM which is not subject to this problem and so far the results have been stellar.
This is the product I used but there are several variations available from many suppliers.
https://www.aliexpress.com/item/33010313163.html
This worked so well and was so easy to implement that I am always surprised that people choose a route subject to wear levelling problems. But who knows? I may still encounter a gotcha further down the road but so far it looks good.
Click to expand...

In my TeenyMIDIPolySynth, as I read the settings for any of the controls that lend themselves to being restored (toggle switches, waveform selections, etc. . . . basically, everything except the pots), I start a 30-second timer anytime anything changes. I delay storing the settings into EEPROM until after nothing has changed for a full 30-seconds (the idea is that several settings are likely to change together, so don't store anything until things settle down). This helps to reduce EEPROM wear in that particular implementation. Don't know if this approach could be utilized in your specific scenario . . .

Mark J Culross
KD5RXT
 
You could add a few electronic components and write the EEPROM only after power-down or in case of brown-out.
That is:
a second 3.3V regulator for powering peripheral -- the MCU and the EEPROM together run on an own regulator
a voltage divider at 5V, tap to a I/O, so it crosses below 0.5V in case of 5V decaying below 3V
a larger capacitor at 3.3V for the MCU.
Attach a high priority interrupt on the IO for transition low and in that interrupt routine write the RAM-data to the EEPROM. Good would be first write a tag "dirty", write all data, overwrite the tag "clean". So you know if the written data are ok when reading them. If not OK, could throw a warning the capacitor is about to die.Or use a checksum scheme, but keep the checksum constantly updated and ready, so no lengthy calculations need to happen on the capacitor power.
 
Seems like EEPROM.put is not working :( I will try eeprom_write_block.

As for the suggestions mentioned by others, thank-you. I already only save settings 5 seconds after the last change to reduce writing. I've also implemented a brown-out detection circuit (using just a resistor and a capacitor) on a TEENSY LC based product I make, which works well enough, but takes an extra IO pin and requires the use of high value capacitors to keep the device going long enough, driving up the BOM cost and taking up extra real estate.
 
Last edited:
Status
Not open for further replies.
Back
Top