Hi. I've a project which uses EEPROM to store values, and the idea is that those values should be stored after shutdown.
It works fine with my Arduino board, but when I use a standalone Atmega328 it doesn't retain the data after poweroff.
I followed this nice tutorial
I've been reading a little and I found this
http://www.societyofrobots.com/member_tutorials/node/309
It shows how to set the the EESAVE on and the BOD at 4.3v recommended by the tutorial author.
How can I do that but using the arduino program? I suppose I have to change the fuse bits, although I don't know the values
thanks
The whole point of EEPROM is to save data through times of power down. The EESAVE fuse bit does NOT enable this to happen. The EESAVE bit when programmed, causes data in the EEPROM to be preserved even when a chip erase command is given with an ICSP programmer.
I believe that most Arduino do not program the EESAVE, but as most programming is done via serial interface, many users will never have to worry about it.
Either you are programming your MCU with an ICSP* (which causes a chip erase) or something else is wrong. If you're programming with an ICSP, just clear the EESAVE bit in the high fuse byte to program it.
*Burning a bootloader will cause a chip erase, and by default, EEPROM will be erased.
I'm programming my chip with another arduino board using SCK, MISO, MOSI... but shouldn't it be erased only when I program it?
I don't have the project at home now, but when I get it i'll test it with a plain sketch just to check the EEPROM data... but the code is almost the same from the other working project which has an arduino board on it.
thanks
capicoso:
I'm programming my chip with another arduino board using SCK, MISO, MOSI... but shouldn't it be erased only when I program it?
That is ICSP programming. And yes, with the default fuse setting, EEPROM should only be erased when programming the chip. I can't imagine what might be wrong if merely cycling power is causing EEPROM data to be lost, I've never seen that.
What's in EEPROM after this happens, are all bytes 0xFF, or just random garbage? If all are 0xFF that would sound like a chip erase, if garbage I dunno, maybe power supply but I'd think it'd have to be doing some unspeakable things!
To be honest I'm not sure what happens with the EEPROM after that. Because I discovered this behaviour when I took my little project to someone's place. And it's still there, but i keep scratching my head wondering...
In the first project(with the arduino board) I write the EEPROM to store banks of presets each bank is 30bytes. Then with up/down buttons I select which bank to write/read. That part of the code is the same on this atmega328...
Maybe it could be something about the supply, not sure. But the thing uses an lcd display, and sometimes it looks like it's taking too much current from the usb.
Also, when i first built this atmega328 circuit, i forgot to solder the AVCC pin, someone said that could have degrade the atmega, in which way i dont know...
capicoso:
...
Maybe it could be something about the supply, not sure. But the thing uses an lcd display, and sometimes it looks like it's taking too much current from the usb.
Also, when i first built this atmega328 circuit, i forgot to solder the AVCC pin, someone said that could have degrade the atmega, in which way i dont know...
My vote is the USB hub chip in the PC... Older PCs cannot supply the 500mA
www.ti.com/lit/an/slyt118/slyt118.pdf
You could try using a bulk capacitor of 10uF if you currently do not have this in your hardware design.
Ray
I am having the same problem with the eeprom locations being set to 0x00 after a reset button press or a power cycle. I wrote a test program outside of my project to write a value to the eeprom location and then I pressed the reset button until the values changed to 0x00 and then did the same thing with power resets to verify that as well. There does not seem to be a pattern as to when the data will be reset to 0x00 but it does happen.
I checked the fuses on the 328 chip today and they are set to preserve eeprom data, low FF, High D6, Ext 05.
I have done some looking and have not found any resolution to this problem. I have verified this on several boards and just tried it on two new boards I received today. They are all Arduiono UNO R3.
Any help is greatly appreciated and I am willing to experiment if needed.
Thanks, Glenn.
glenndrives:
I am having the same problem with the eeprom locations being set to 0x00 after a reset button press or a power cycle. I wrote a test program outside of my project to write a value to the eeprom location and then I pressed the reset button until the values changed to 0x00 and then did the same thing with power resets to verify that as well. There does not seem to be a pattern as to when the data will be reset to 0x00 but it does happen.
I checked the fuses on the 328 chip today and they are set to preserve eeprom data, low FF, High D6, Ext 05.
I have done some looking and have not found any resolution to this problem. I have verified this on several boards and just tried it on two new boards I received today. They are all Arduiono UNO R3.
Any help is greatly appreciated and I am willing to experiment if needed.
Thanks, Glenn.
Whittle it down to the smallest possible code that demonstrates the issue, and post it here, we can then better analyze and/or test it. Disconnect all attached devices and remove any related libraries.
I am having the same problem with the eeprom locations being set to 0x00 after a reset button press or a power cycle. I wrote a test program outside of my project to write a value to the eeprom location and then I pressed the reset button until the values changed to 0x00 and then did the same thing with power resets to verify that as well.
This makes no sense (to me) on production Arduino hardware. I use EEPROM.h in many programs and have never seen this problem. I do not doubt you, but are you using the EEPROM.write( address, byte var) correctly? That is, have you cast your variable as byte appropriately?
Other thought for nonproduction h/w, perhaps the brown-out fuse is incorrect... Thus should not happen with an UNO unless perhaps the uC has been replaced.
Every board should have a bulk capacitor to ensure the voltage at power off (via switch) drops to the uC in a manner that allows the brown-out circuitry to shut down the uC. Purposefully pressing reset over & over while the program could be in an EEPROM.write() function is ill advised.
I use the EEPROM functions here twice and have never had any issues.
http://www.hackster.io/rayburne/magic-morse-on-arduino
Ray
mrburnette:
This makes no sense (to me) on production Arduino hardware.
Agree. Highly unusual. So another question for @glenndrives and @capicoso would be, Where did the boards come from and are they official Arduino boards?
Other thought for nonproduction h/w, perhaps the brown-out fuse is incorrect... Thus should not happen with an UNO unless perhaps the uC has been replaced.
glenn's fuses indicate the 2.7V BOD setting, standard for an Uno. As I mentioned above, programming the EESAVE bit (bit 3 in HFUSE) causes EEPROM to be preserved through a chip erase. EEPROM should always be preserved through a power-on reset or external reset (button) regardless of the state of EESAVE.
glenndrives:
I checked the fuses on the 328 chip today and they are set to preserve eeprom data, low FF, High D6, Ext 05.
glenn's fuses indicate the 2.7V BOD setting, standard for an Uno.
So, question for Glenn is did he read the fuses via AVRDUDE or just look st the boards.text file?
Yes, I read that but the BOD anticipates a voltage reduction based on the exponential decay of the bulk capacitor. A "poor" filter cap could be suspect or a high current drain causing a near vertical drop of voltage. USB specs limit the bulk cap to 10uF (the TI document) but the external power supply has no such restrictions.
Ray
Well, This is a bit embarasing. It turns out that I was not properly writing the value to the eeprom location using a routine to read a rotary encoder. I had whittled the code down before to where I thought I was testing properly but I was mistaken.
What I did was start over with one sketch that wrote to several eeprom addresses and then another that read those addresses and displayed the contents. Once that proved to work I continued to add my other code in until it broke and then I fixed it.
are you using the EEPROM.write( address, byte var) correctly?
Yes, this is one of the first things that I checked.
Every board should have a bulk capacitor to ensure the voltage at power off (via switch) drops to the uC in a manner that allows the brown-out circuitry to shut down the uC.
There is one after the power supply for this reason. I was testing by removing the power.
Purposefully pressing reset over & over while the program could be in an EEPROM.write() function is ill advised.
Yes, this is ill advised but did not seem to cause any problem during testing once I figured out my mistake.
Agree. Highly unusual. So another question for @glenndrives and @capicoso would be, Where did the boards come from and are they official Arduino boards?
These are original Arduino UNO R3 boards.
So, question for Glenn is did he read the fuses via AVRDUDE or just look st the boards.text file?
I did read the fuses via AVRDUDE using another UNO with the Arduino ISP.
Thank you all for the replies I appreciate the help.
Glenn
Reply #3 rules over all others. 
Occam's razor true this time, but many of us being such arduino nerds we tend to try and find the most obscure possibility first. Pressing the reset button too much or too quickly, really. 
Glad you figured it out, Glenn!