Go Down

Topic: EEPROM memory-stomping bug? (Read 2 times) previous topic - next topic


I don't have the code with me to post just now, but I'm working on a system with an Arudino Uno, which uses EEPROM to store some data.  I'm using ArduinoUnit to code it up using Test Driven Design techniques.  While doing this, I've run across what appears to be an EEPROM bug: I create some data structures in RAM, and as soon as an EEPROM.read() or EEPROM.write() call occurs, subsequent tests on those data structures fail.  I can move the EEPROM calls around in the test list, and tests reliably start failing as soon as EEPROM is accessed.

I can post code and exact version numbers of everything when I get home again, but in the mean time, does any one know whether the EEPROM code depends solely on Arduino IDE code, or if it requires system code?  I'm running the IDE on Ubuntu, and didn't see problems like this the last time I used the IDE, with version 0022.  Obviously both Ubuntu and the IDE have changed a lot since those days.

I ask because I traced back through the EEPROM code, and it links to to /usr/lib/avr libraries, which I suspect are maintained by Ubuntu as opposed to by Arduino.

I need to do more testing before I can categorically state that this is an Arduino bug (as opposed to a flaw in my board, or a flaw in Ubuntu), but I figured I'd ask and see if anyone can help me out in the mean time.  Thoughts?


EEPROM has only a (very) limited # of write cycles ,
don't know the exact number but I can imagine that a test can reach this number within an hour or
so ruining at least that address ... ruining your test ... etc?

Can you post some code?
Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)


According to the 328 spec (on the data sheet: http://www.atmel.com/dyn/resources/prod_documents/8271S.pdf), the Flash is rated for 10,000 read/write cycles, and the EEPROM for 100,000 (or 10x more than Flash).  I agree one should be careful about excessive access to memory, but my ~2 dozen test runs with one read/write cycle each aren't a concern.  It's a good warning to keep in mind, though.

I can post code in about 8 hours, and hopefully I can narrow it down to a very limited set of tests so the code sample isn't too huge. ;)


Here's the code that's failing for me.  I've reduced it to just the system which is failing and will be working soon on using different boards and computers to explore the limits of the bug.


Indeed, tested the exact same code using 1.0.3 on a Mac, and no bug.  I think there's got to be a bug in the Ubuntu AVR libraries.  I'd be interested to hear from other people running Ubuntu 12.04 LTS whether they also see the problem.  The bug output is reproduced in the comments of scheduler_test.ino.

Go Up