EEPROM not saving with a restart

I am using 1.6.9 and EEPROM.put / EEPROM.get which is working fine while the Sketch is running and a “get” will show the revised "put’ value.

But, if I stop and start again, it has cleared the EEPROM and uses the default values.

Any thoughts on why this is happening?

When your sketch is loaded into the Arduino, there is a way of either reloading the EEPROM each time or not touching it. I don't know which is the default but perhaps the EEPROM contents are being reloaded on each upload? Someone more familiar with the process could clarify that for us.

Pete

el_supremo: I don't know which is the default but perhaps the EEPROM contents are being reloaded on each upload

Pete thanks, that is exactly what seems to be happening, or the "put" is not permanent with a restart. That is nuts as the EEPROM is supposed to be immune to restarts and power off etc.

Reading on the "EEPROM.put" help page they mention EEPROM.update so it seems like I may need to cripple that or activate it whichever is needed. Seems like that EEPROM.update is screwed up.

https://www.arduino.cc/en/Reference/EEPROMPut "Note This function uses EEPROM.update() to perform the write, so does not rewrites the value if it didn't change.

It would be so much easier to provide help if you posted your code .....

they mention EEPROM.update

That is a different thing entirely. When you write a value to an EEPROM, the location must first be in the erased state which means that it is all ones 0xFF. When you write a value to the EEPROM, it only changes 1 to 0. What update does (I think) is that it keeps track of what you wrote previously at that location and if it hasn’t changed, it does nothing. And, perhaps, if the new value only requires changing 1 to 0, it will do that without requiring an erase cycle first - which takes much longer than a write or a read, and on larger EEPROMs you can only erase a sector at a time.

What I was talking about is the upload process when you compile and upload your code to the Arduino.

But I agree with UKHeliBob, it would also help to see your code (between code tags please - the </> icon will generate them for you).

Pete

I use EEPROMex library as it gives me some more flexibility (support of different data types out of the box). EEPROM.updateByte (0, 5);
first looks at (reads) the content of location “0” and writes byte “5” to that address if it read a different value and does nothing if it found already a “5”.

Never had a problem with this library and I used it a lot.

el_supremo: there is a way of either reloading the EEPROM each time or not touching it.

Not if Optiboot is involved. There is not enough space available for Optiboot to do anything with EEPROM. The EEPROM commands are ignored (or a generic error is returned).

@Coding Badly: does Optiboot leave the EEPROM alone, or does it always initialize it (presumably a chip erase)?

Pete

Reply #6, second sentence. :wink:

(I will confirm in a few minutes.)

But, if I stop and start again, it has cleared the EEPROM and uses the default values. Any thoughts on why this is happening?

So, first step is to post some simple code which demonstrates the problem and let others confirm or not confirm what you see.

If it can be confirmed that there is no problem with your code, and other people can use it and restart with preserved values, then there is possibly a problem with the fuse settings on your processor.

Which Arduino are you using? What is its history? Are you loading your programs with USB serial, or are you using ICSP?

[EDIT: Differentiate between icsp and bootloader for fuse issues.]

In the 8 bit processors, the "high byte fuse" has a setting for EESAVE which preserves the eeprom through a chip erase if you are loading code with the ICSP. It does not matter if using the bootloader and loading the sketch with usb.

If your problem can be confirmed, and you are using the ICSP and not the bootloader, you will need to reprogram the fuse settings.

Ahh. I haven’t played with Optiboot. I was picturing it as doing a chip erase unless it received EEPROM commands. Apparently not.

Pete

Note from the developer (currently @westfw)... https://github.com/Optiboot/optiboot/blob/master/optiboot/bootloaders/optiboot/optiboot.c#L118-L122

No matter how Optiboot is built there is no EEPROM erase in the source code. Reading / writing pages (one byte at a time) is optionally supported but that is disabled in the Arduino world.

I've just done the old "try it yourself and see" trick. On a NANO, using EEPROM.read and EEPROM.write, I wrote to the EEPROM, powered off and then rebooted. Rereading the EEPROM shows that the EEPROM is not erased on power up. So whatever is written to the EEPROM should survive a power down and reboot.

@SalineSolution: post your code (between code tags please)

Pete

rpt007:
I use EEPROMex library as it gives me some more flexibility (support of different data types out of the box). EEPROM.updateByte (0, 5);
first looks at (reads) the content of location “0” and writes byte “5” to that address if it read a different value and does nothing if it found already a “5”.

Never had a problem with this library and I used it a lot.

The EEPROM library supports any data type out of the box, including arrays (that is specifically what the get() and put() functions are for).

@pYro_65:

You are absolutley right, but: Some months ago I was (I sometimes feel being it today as well) a total newbie. In my project there was a request to store values permanently and keeping them updated while the sketch was running and the user modified some parameters.

As my project was already a challenge for a newbie, I easied my life after some frustrating attempts with the "normal" EEPROM library with the EEPROMex, as this worked as expected right away and no hazzle with data types and the way they are to be stored / read in the right order etc.

Now I know I can do it with the normal library, but then it was a great relief for me and I got the results without losing too much time on that partial challenge of the overall project where my limited time was a more effective and efficient invest.

el_supremo: When your sketch is loaded into the Arduino, there is a way of either reloading the EEPROM each time or not touching it. I don't know which is the default but perhaps the EEPROM contents are being reloaded on each upload? Someone more familiar with the process could clarify that for us.

Pete

Be aware that OP stated 'stop and start', not upload a new sketch :)

Let's wait for some code. I think OP is also using a CRC routine and might have made a mistake in that ;)

Thanks all, I found the culprit, it turned out to be a fork of the LCD Library I had unwittingly used. Lesson learned. The damned naming convention for Libraries is a nightmare. Library developers should not be allowed to name their fork the same a the base Library name.

There was too much code to post, so I went back to a basic Sketch and it all worked fine, so then I started remming-out one Library at a time along with their associated parts in my Sketch. The damned fork was clearing a small part of EEPROM for it's own use and no mention of it in the .MD or Keywords files. Just happened to be the same spot I was using.