EEPROM write cycles

[mark2]

I was thinking about the cost/benefit long-term of using socketed replaceable EEPROMs for knob presets or the state of the last used bypass/engage for relay-switching... i.e. things that may be written many times.

I've always been hesitant to use the built-in AVR ones since, compared to say a 24lc32a and its 1mil+ cycles, an attiny/atmega has "only" 100,000+. Granted that can last a very long time, but it's not uncommon to see 30-40 year old pedals still in use. Replacing a socketed off-the-shelf eeprom seems a far better long term plan than trying to replace a soldered SMD, custom-programmed uC.

Curious, I opened up the back of my OBNE dark star and sunlight, and sure enough it would seem at a glance they are probably using the shorter life built in AVR eeprom.

Do you think they're okay with their pedals simply being long-term disposable? Or am I misunderstanding something? (assuming I didn't miss another form of storage, which I don't think I did).

[niektb]

well we can calculate... how often do you power cycle, adjust and save presets? Lets average on two write cycles a day? Meaning 730 cycles a year, meaning your eeprom will last 137 years guaranteed... (when just looking at write cycles ofc )

[ElectricDruid]

+1 what Niektb said.

There's ways to avoid writing to the EEPROM unnecessarily, like only storing the state when the pedal powers down, and like that a 100,000 cycle average lifetime can easily be enough.

[niektb]

Also, it's important to note what a write cycle is: https://microchipsupport.force.com/s/article/What-is-Endurance-of-EEPROM
It's not the EEPROM as a whole but évery cell has that endurance specification. Meaning you can write 100k times to cell no. 1 and cell no. 2 will still work perfectly

[mark2]

Meaning 730 cycles a year, meaning your eeprom will last 137 years guaranteed... (when just looking at write cycles ofc )

Well, I was admittedly using far more aggressive worst-case estimates for saving both presets and the state of the bypass.  It's feasible to limit it to 10  years.

There's ways to avoid writing to the EEPROM unnecessarily, like only storing the state when the pedal powers down, and like that a 100,000 cycle average lifetime can easily be enough.

That would require a battery though, no?
As best as I can tell these are saving immediately, and not doing any batching.

you can write 100k times to cell no. 1 and cell no. 2 will still work perfectly

Yeah, it wouldn't be terribly complicated to have it simply rotate through a reasonable number of write locations when you're only storing small amounts state info. And use some sort of flag preceding each location to indicate if it's the active one.

[pruttelherrie]

There's ways to avoid writing to the EEPROM unnecessarily, like only storing the state when the pedal powers down, and like that a 100,000 cycle average lifetime can easily be enough.

That would require a battery though, no?
As best as I can tell these are saving immediately, and not doing any batching.

There are tricks for that, can't find the article 1-2-3 but I'll try to describe it from memory:
* Make sure the MCU is fed through a diode and a large-ish electro
* Feed the power-in to a resistive divider into an ADC pin
* Monitor this pin
* Keep your settings/programs/whatever in RAM (copy from EEPROM upon boot)
* As soon as the power starts to fall/fail, write the in-RAM stuff back to EEPROM. Since the MCU is at this time powered separately all stored energy in that electro should be able to keep it up long enough, couple of 100ms ?

you can write 100k times to cell no. 1 and cell no. 2 will still work perfectly

That works on AVR (and on PIC? I have no experience with those) but on STM32, every single byte write will actually overwrite a whole frigging page since it only support page writes?!?! Found out the hard way, now I'm using "emulated EEPROM" which resides in RAM, and is written back to EEPROM on demand. Which is actually not so bad, since combining the code with the procedure described above is only logical.
In my projects I keep all those variables in a struct so writing it back takes just one call.

[pruttelherrie]

There are tricks for that, can't find the article 1-2-3 but I'll try to describe it from memory:

Wait a sec! Found it: https://www.thecoderscorner.com/electronics/microcontrollers/psu-control/detecting-power-loss-in-powersupply/

[ElectricDruid]

+1 what Pruttelherrie said. That's pretty much exactly the way I've done it.

And, yes, you can write single bytes of EEPROM on the PIC.

[mark2]

Great trick. Makes a lot of sense.  Obviously you'd need to ensure the cap is large enough so as not to make the problem worse with a corrupted EEPROM if it loses power during your write.

[pruttelherrie]

And here's some more info from Atmel on cycling through the addresses: "AVR101: High Endurance EEPROM Storage" https://ww1.microchip.com/downloads/en/appnotes/doc2526.pdf

[mark2]

Thanks; I just came across that as well. Theirs seems to be on the slightly more complicated end of the spectrum.
And I discovered a term that made googling this a bit easier: "wear leveling"

So far everything I've read seems needlessly wasteful or complicated for this use case.

I'll do more reading, but am inclined to use my own algorithm that takes advantage of the fact that a long boot up time is quite acceptable for pedals. Namely: on startup, read each byte or word until you find one with a flag bit set indicating it's the current value.  Remember that position in RAM.

That's incredibly simple and lets you get 128x more use out of an attiny84/85: (512B total) / (2B per word) / (2 writes per save). Or even 16x more from an attiny13.

[Sweetalk]

Interesting discussion. I think that there's other parts in a digital pedal that will shorter the lifetime before the EEPROM or AVR memory cycles will. I'll give them a good 30-40 years of good use, that's enough I think, considering that today's appliances in general consumer electronics dies like in a year or two