Many thanks for the help, and where do EEPROMS go to die?

Hi, I posted a thread as a noob a few months back about this project, and was given great advice that a Nano would do the job required. And it has. I've a small 5 axis mill/engraver at home, so have cut the casings and PCB'c (should be called MCB's (machined not printed lol))

Above are two devices (left) the BME280 housing (below left) and then the main PCB/MCB's. The Nano goes on the larger board after the resistors, jumpers (GND & SDA) and RGB LED and OLED headers are soldered. Then solder the Nano and place on the top board with the three buttons and 20mm speaker

|500x375 Medical grade Nylon is uncoloured, and LED's look great in it, the red is from the Nano's power light!!! I did put black enamel on one to take it out. But my boy likes the I'Robot look lol. The green is from the RGB LED on it's lowest PWM power setting, as the BMP goes up from 0 to target it glows brighter, then turns blue at correct pressure. Red for over pressure. The lump of plastic the parts are sat on is billet cast Nylon.

Pins used are...

3,6,9 PWM to the LED A1 speaker 2,7,11 buttons A4,A5 I2C to OLED and BME280 5v to buttons 3.3v to BME280 both GNDs are used and connected via the top board.

The sketch does two types of lung physio (button/menu selected), and allows setting changes stored on the EEPROM to all settings. I know the EEPROM is 'Lifed' so I'm staying away from Writes and using Put and Update instead. However I'm also only using 15 EEPROM addresses (I think the Nano has 1024 but dont know for sure???) so could include an EEPROM register to shift user settings up the addresses if one fails? Do EEPROMs fail in the same way? do they go High to Heaven or Low to Hell? can you tell? I spose a bit of code with Write/Read, did what was written return would tell!

Anyway, many thanks for the advice to date, I'm off to buy a Mega for the next project :o

Phil.

"Anyway, many thanks for the advice to date, I’m off to by a Mega for the next project :o "

Or a Mega DIP

MegaDipBreadboard.jpg

.

larryd:
"Anyway, many thanks for the advice to date, I’m off to by a Mega for the next project :o "

Or a Mega DIP

MegaDipBreadboard.jpg

.

I click faster than that, got a Mega with nice shiney case on the way :slight_smile: that said your Mega looks very interesting in a big way due to it’s width! around 22mm?? would fit edge up in billet machined inch Nylon. which is very interesting to me, more so than the stock Mega

The above device was for my Sons Physio, he has a condition, my next device, the one I’m now working on is his med box. A smart med box, he forgets to take things. not just the drugs in the box but drugs in the fridge too. Design brief in brief would be…

Must Haves…

Lots of program space, like the 256K of the Mega
Take a RTC I2C
Take I2C display
Take SD SPI /record use
14 input switches (draw open roller switches) 14=AM & PM for 7 day
Speaker/alarm
14 output to LED to indicate drawer to open/take (he often takes to correct drug from the wrong day)
Take a good internal battery supply.
And a few buttons to use/program…Alarm off/ box filled.

Software side will be very nice, 10pm Insulin is in the fridge not the box, it’d be great to have Arduino thinking ‘outside the box’ and alarming a Star Wars tune in the kitchen as a reminder

I’m very interest due to the size,

Phil.

"your Mega looks very interesting"
This is Crossroads Mega DIP board.
I got a few from him a while back, works great.

He has all the pins available to the user.
86 I/O pins.

I put one on a second story for test purposes.

.

darthclueless:
However I’m also only using 15 EEPROM addresses (I think the Nano has 1024 but dont know for sure???) so could include an EEPROM register to shift user settings up the addresses if one fails? Do EEPROMs fail in the same way? do they go High to Heaven or Low to Hell? can you tell? I spose a bit of code with Write/Read, did what was written return would tell!

To actually give advice about this question:

The attached application note describes how to implement a circular buffer in EEPROM in order to spread the writes out over a larger area of the EEPROM in order to multiply its life. It uses generic flowcharts to describe the algorithm so it requires some translation to the Arduino functions, but it’s not very complicated.

AVR101 - High Endurance EEPROM Storage.pdf (47.3 KB)

Erased EEPROM is all bits set? I forget, it's 00 or FF. When the sketch writes the 15 bytes then it writes 1 that is opposite to erased as a terminator.

In setup() the sketch checks the EEPROM from top down looking for the terminator of the last save written. The next address is where to write next. 16 bytes before the write next is the last save.

If the top-down EEPROM search starts with a terminator, load the last save from terminator - 15 then erase EEPROM. Next save will be at address 0.

AVR EEPROM lifetime is >= 100,000 page erases.

If you saved once per minute, every minute for 12 years and 2 months then tomorrow you might get EEPROM failure.

Search up on rugged circuits quadram card. They are plug-in external RAM for Mega2560. The 512KB gives you 8 banks of 56-usable-K heap space while the internal 8K RAM becomes dedicated stack space.

All ATmega hardware serial ports are capable of master mode SPI, and the 2560 has 4 plus 1 full SPI port, can connect as slave or master. Given that the data lines are MOSI - master out slave in - and MISO - vice versa - it's not possible to directly route data between 2 slaves. But slaves on 2 different SPI buses, an AVR "hub" can read from one and write to the other at speed without buffering. Otherwise the transfer takes twice as long.

Note that even the 328P has a serial port and an SPI port. IMO one would make a neat SPI bus buffer/controller for SD.

Thanks for the advice guyz, I think the...

If you saved once per minute, every minute for 12 years and 2 months then tomorrow you might get EEPROM failure.

...comment sums it up though. I'll forget about the EEPROM, if it aint broke don't try and fix it :)

GoForSmoke: n setup() the sketch checks the EEPROM from top down looking for the terminator of the last save written. The next address is where to write next. 16 bytes before the write next is the last save.

If the top-down EEPROM search starts with a terminator, load the last save from terminator - 15 then erase EEPROM. Next save will be at address 0.

AVR EEPROM lifetime is >= 100,000 page erases.

If you saved once per minute, every minute for 12 years and 2 months then tomorrow you might get EEPROM failure.

Such a procedure requires a little bit of extra fiddling than most people are used to using with the EEPROM libraries. In particular, the Programming Mode bits in the EECR need to be set to the right values. By default it will perform an erase+write cycle every time it writes, but you can change them to perform just writing or just erasing. If you leave it default it cuts your calculation in half.

darthclueless: ...comment sums it up though. I'll forget about the EEPROM, if it aint broke don't try and fix it :)

That's only using his wear spreading algorithm. If you write to the same location every time (once per minute, 24/7), you're minimum life drops to to just over 2 months.

You'll have to analyze your situation based on your expected write frequency.

Jiggy-Ninja: Such a procedure requires a little bit of extra fiddling than most people are used to using with the EEPROM libraries. In particular, the Programming Mode bits in the EECR need to be set to the right values. By default it will perform an erase+write cycle every time it writes, but you can change them to perform just writing or just erasing. If you leave it default it cuts your calculation in half.

I don't like to waste and I know what I can do with what I've read from the datasheet. If that takes some work and some functions have to be written, it's not rocket science, it's programming.

Those who do the work get better at it.

Even at default; 64 saves before wiping the slate (to know which save was last) 50,000 times over is going to need buttons that don't wear out first.

Perhaps a better scheme for default operation would be a 32-bit record number followed by a fixed-length record. Then what record is last will have the highest record number. 53 19-byte saves can be made before overwriting the first. At startup check EEPROM from low to high to find the highest record number and that will be the last save.

These are file techniques from the days when 128 to 360KB floppies was all many places had. A 5 or 10MB HD was more about the speed than the capacity, tape drives were about capacity.

The old ways suit AVR's well. There was a time when 1KB was a lot of RAM and what they did to stretch that will work on a 328P with SD very well with some modifications. The things that were done to get those old devices to shine do work even better with Arduinos.

GoForSmoke: I don't like to waste and I know what I can do with what I've read from the datasheet. If that takes some work and some functions have to be written, it's not rocket science, it's programming.

Those who do the work get better at it.

It's worthwhile to make explicit things that are subtle like that. Small details can easily get missed if they aren't mentioned.

Perhaps a better scheme for default operation would be a 32-bit record number followed by a fixed-length record. Then what record is last will have the highest record number. 53 19-byte saves can be made before overwriting the first. At startup check EEPROM from low to high to find the highest record number and that will be the last save.

That's the method outlined in the app note I posted.

Save number could be 3 bytes stored + 15 bytes data = 56 saves in 1024 bytes, 5,600,000 saves before EEPROM fails are expected will fit in 24 bits (0 to >16 million). The top 16 bytes don’t get used, still open.

5,600,000 saves is every minute for 10 years, 7 months, in the 23rd day the warranty runs out due to overuse.

I like my 1st way better, it might do saves in less than a minute.Buttons might not be involved.

Another solution for the OP is to use external EEPROM on SPI, I2C or other serial bus. If that wears out, replace the chip.

GoForSmoke: Save number could be 3 bytes stored + 15 bytes data = 56 saves in 1024 bytes, 5,600,000 saves before EEPROM fails are expected will fit in 24 bits (0 to >16 million). The top 16 bytes don't get used, still open.

You only need one byte for the index value. Instead of finding the largest number in the bunch, find the position whose value is not exactly 1 less than the next value. As long as the number of positions in the ring is less than 256 this will handle the wrap-around perfectly fine, just like millis interval calculations (0 - FF = 1 in unsigned 8-bit arithmetic).

Example:

[ FD   FE   FF   00   01  02   FA   FB   FC ]
                          ^^ current position is this one

A trick that I use for EEPROM, is to keep the values in RAM, then sensing an orderly shutdown/reset - or supply failure (with an analog input), I write the EEPROM while the supply drops (plenty of time - even for a couple of KB by using a capacitor), then HALT to avoid any other processing until the system recovers.

I take samples - often up to every few milliseconds, but only write to EEPROM rarely, or when the cpu is going down.

Jiggy-Ninja:
You only need one byte for the index value. Instead of finding the largest number in the bunch, find the position whose value is not exactly 1 less than the next value. As long as the number of positions in the ring is less than 256 this will handle the wrap-around perfectly fine, just like millis interval calculations (0 - FF = 1 in unsigned 8-bit arithmetic).

Example:

[ FD   FE   FF   00   01  02   FA   FB   FC ]
                          ^^ current position is this one

Even better!

Jiggy-Ninja: You only need one byte for the index value.

Two. And a CRC. Otherwise there is no way to detect when an index byte fails. Which are more likely to fail because they are written as often or more often than data.

That is, if there is a need to detect a failure. Which seems rather important in this context.

LOL Thanks for the replies/advice guyz,

I've read them 5 times and feel only slightly wiser, than I was before I read them for the first time :o

I will continue to go back over them for future reference/use.

But after first posting and the first replies I don't think I'll have a problem with EEPROM failure for a long time.

I am only using a few EEPROM addresses, and there use is not often. They are of different types in terms of use and amount of writes.

1) Sound on/off in user settings

2) user settings adjust (about 20 addresses)

3) BME280 Calibration Value (not used until the BME fails)

4) First ever power on event, written to only once.

5) cycles completed (should write/be used twice per day)

6) Power on event (should write/be used twice per day)

So it's really 5) & 6) that will EEPROM write most often, I've programmed them the same way in different addresses, one address counts 1+1 to 255, then zeros that address and the second address counts how many 255's have happened. The program does the Math and counts (should) to 65,025 events. Which is well below the 100,000 write of the EPROM itself.

So my little Nano's EEPROM wont (should not) blow. but the program goes tits up in 178.02874 years!!

Many thanks for the advice and help.

darthclueless: LOL Thanks for the replies/advice guyz,

I've read them 5 times and feel only slightly wiser, than I was before I read them for the first time :o

I will continue to go back over them for future reference/use.

But after first posting and the first replies I don't think I'll have a problem with EEPROM failure for a long time.

I am only using a few EEPROM addresses, and there use is not often. They are of different types in terms of use and amount of writes.

1) Sound on/off in user settings

2) user settings adjust (about 20 addresses)

3) BME280 Calibration Value (not used until the BME fails)

4) First ever power on event, written to only once.

5) cycles completed (should write/be used twice per day)

6) Power on event (should write/be used twice per day)

So it's really 5) & 6) that will EEPROM write most often, I've programmed them the same way in different addresses, one address counts 1+1 to 255, then zeros that address and the second address counts how many 255's have happened. The program does the Math and counts (should) to 65,025 events. Which is well below the 100,000 write of the EPROM itself.

So my little Nano's EEPROM wont (should not) blow. but the program goes tits up in 178.02874 years!!

Many thanks for the advice and help.

You should only save when user forces a save and as part of shutdown. Why save at startup? That's when you load the last save, which you have or you couldn't load it and reload as often as you want. Better yet, only save values that changed and your CRC if it's changed. Then if nothing changes for a long time, the EEPROM won't get any wear the whole time. The last save stays last, AVR EEPROM is spec'd for at least 50,000 writes.

There are 8766 hours in a year, once per hour for 5 years, 8 months and on the 14th day, plus every hour you don't make a save, replace the controller. If you save twice a day every day, you should get over 68 years out of 50000 writes. That does not include only saving changed bytes.

GoForSmoke: You should only save when user forces a save and as part of shutdown. Why save at startup? That's when you load the last save, which you have or you couldn't load it and reload as often as you want. Better yet, only save values that changed and your CRC if it's changed. Then if nothing changes for a long time, the EEPROM won't get any wear the whole time. The last save stays last, AVR EEPROM is spec'd for at least 50,000 writes.

There are 8766 hours in a year, once per hour for 5 years, 8 months and on the 14th day, plus every hour you don't make a save, replace the controller. If you save twice a day every day, you should get over 68 years out of 50000 writes. That does not include only saving changed bytes.

Hi GoForSmoke,

I don't save anything at start up other than one EERPOM address counter that I 'require to know' how many 'start ups' has the device done? There is no menu option to get this data from the EEPROM on the device options menu, but if you hold down button 1 on the back at start up it displays the EEPROM data on the OLED for 10 seconds, then continues with program as normal. saves are only forced by the user using the EEPROM.update command, thus saving more writes. The nature of the device is such that the user would not be making changes daily. More likely once a month or so.

So a typical month (30 day) will see, 60 power on writes, 60 cycle complete writes on the EEPROM

I have OCOED, Obsessive Compulsive Over Engineering Disorder. And I'm proud to say that I'm no longer worried about burning the EEPROM. All is fine, nothing needs improving....well not today ;)

I remembered that I had an old Nano that was beyond use due to being soldered on and off prototype boards, a few of the header tracks had come away from the board. It is however fully working. I very nearly threw it away, glad I did not. So I thought I'd try to answer my own question.

And what is very reassuring is, that I am at the moment struggling to blow it up!

I've written a short sketch which basically uses a loop to eeprom.write to address 'x' from zero to 254.

Then write a know value to it, and then check the same value returns from it. If it does it loops on counting on an unsigned int to 65K.

when the unsigned int gets to 65k a second counter counts how many 65k's have been written

It' printing out values to the serial port so that I can see what's going on. The loop will stop when the EEPROM fails to return the set value.

at the moment it's written to it 230,000 times and counting!!!