Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

[AVR] EEPROM Data Corrupted after 3 days of continuous run

Status
Not open for further replies.

Zyber

Newbie level 1
Joined
Oct 13, 2017
Messages
1
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Activity points
12
Hello all,
I did a Home Automation System using Atmega328p. I have used EEPROM to store a variable which is written only once and can be read from the EEPROM location every time the system restarts . But after one week of successful run, the value read from the location is corrupted and the system fails. Why is this happening since I am not even updating the EEPROM value.
Please guide me through.
Regards,
Bimal Satheesh
 

Hi,

post your complete code.
What about fuse settings, like brown-out,
what voltage,
other information that is not included in the code...

Klaus
 

Might check the write cycle timing and such, vs the mfr's
expectations. Retention can be much worse if write time
or write voltage is below spec (above spec tends to go to
write cycle endurance or damage).

Also might check that the value is indeed corrupted at
the word level, and that this is not a read intermittent
type error. Getting the same, but wrong, answer over
N readbacks would answer that.
 

I have used EEPROM to store a variable which is written only once and can be read from the EEPROM location every time the system restarts

The most likely cause may be only an issue at the firmware side, such as not checking the power voltage right before performing read/write to the memory, or not meeting the required timing. However, in situations where we do not fully trunst the stored value, it is convenient to adopt an error checking code (parity, checksum, CRC, etc ...) in such a way that when reading or writing the data from/to the memory, always check if there was an error indication. Additionally, other strategies can be used together, such as performing multiple re-read attempts (say, up to 3) in case the first one did not get the correct result in the error check, or try another position in memory, but that all may be unnecessary if you just verify that your firmware is meeting the minimum timing and voltage requirements.
 

Assuming this is not a firmware problem, EEPROM data can be corrupted due to glitches on the power supply, Which may be due to switch bounce on the on/off switch etc. A large capacitor across the supply rails should cure this problem.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top