Hi All,
I stored a byte value to the atmega 328 eeprom, But when a change in the Supply occurs ( a glitch at the input voltage), the value at the eeprom gets erased...What may be the issue, I enabled the Brown Out detection(Working at 4.99 volts so i set the bod as 4.3).but the issue is still existing.....Please help me..
Ajin nadh.v.a
The AVR EEPROM is permanent storage and independent of the power supply. Please show us a short sketch of how you write and read the EEPROM. BTW what do you mean by "erased"? The default contents of an "empty" EEPROM byte is 0xFF. Do you read that value?
eeprom security is not independent of the power supply. Since these devices were first created it is known that slow and/or noisy power rise and fall times can corrupt flash and eeprom. for this reason it is important to use bod as mentioned but also clean and fast rise/fall times.
fast rise is easy but fast fall tricky if there is a light load. adding resistor or light bulb works or special circuit to discharge quickly. normally these measures are not necessary and data is stable but not if rise and fall are unusually long. its also possible to improve security by adding special qualifier code to the ee write routine but arduino library does not do this. other software tricks can help too.
also note that another of what i consider poor decisions by arduino is default fuses set to erase eeprom on every program upload. however this is unrelated to the above.
OP did not mention that his power supply is unstable WHILE the EEPROM write takes place. This sure would be a problem. But once written the contents are no longer prone to power outages.
BTW EEPROM is not erased by uploading a new sketch, at least not on my genuine UNO R3.
EEPROM is not erased by uploading a new sketch via serial. When you 'burn bootloader' or upload sketches via ISP header, it is erased (this can be controlled by a bit in the high fuse - but on the Uno, it's set to
I've never had EEPROM data corrupted due to power supply problems. I never tried to unplug them while they were writing to the eeprom or anything though.
i did mean to say when program is uploaded by isp. very inconvenient for projects like multiwii where all calibration and user settings are lost. using correct fuse avoids this.
obviously data can be corrupted if power is removed or unstable while writing to ee but that has nothing to do with my comments. mostly its caused by slow rise/fall regardless of what mcu is doing.
ee corruption is generally rare in most arduino setups and relatively few even use that feature so not surprising some deny its a problem. op (and i) know different. for example uno discharges quickly because of small caps and high idle current. this is a case where big supply caps can work against you.
also worth mentioning that location zero is orders of magnitude more susceptible with adjacent address not far behind. thats why i always start at locations 1/3 the way up which are more resistant.
another thing to note is that if there is no ee write code anywhere in the program much less chance. so data loaded with a programmer is relatively secure.