EEPROM corruption on addresses 0 and 1

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello freaks!
I have a built a fridge controller which uses one byte of EEPROM for storing the setpoint. On startup, the value loaded from EEPROM is displayed for a second before continuing.

Works beautifully as long as I don't use EEPROM address 0 or 1. The setpoint will be trashed and set to some semi-random value (apparently not too far from the saved one). I test this with the reset button on the stk500 connected through 6-pin ISP. On address 1, the value might be different the first few times before it settles.

The specifics:
Tiny26
Internal RC osc at 8 MHz
Brown-out detector at 4V
WinAvr 20070122
F_CPU correctly defined in the makefile.

I'm accessing EEPROM with the functions from , specifically "eeprom_write_byte" and "eeprom_read_byte". I am using cli() and sei() before and after accessing EEPROM.

I vaguely remember similar issues, but only on address 0 and on older devices. Unable to find any posts now.

This is no real problem for this application, of course. But it would be nice to know if there are issues with the low EEPROM locations, or if I just messed up :)

So, am I missing something here?
Anyone with similar experiences?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi

Pretty sure the problem still exist in the ATtiny26 & earlier chips AT90s series.
Still avoid address location 0.
But don't know about the latest version chips.

Maybe someone else can enlighten us on the more recent chips.

Ken

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

On older AVRs EEPROM problems are known during power off and on, but never on a new reset of an already powered device.

So, if you have problems without power off and on, then the problem must be inside your code.

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The symptom is present without power cycling. I just press the reset button on the stk500 while the whole thing is powered. The value read is displayed for a short time, as I described in the original post.

I don't see how power cycling can have anything to do with this, as I have brown-out detection at 4V. That should ensure all execution stops when power is insufficient.

I have found a semi-related issue in an errata for the at90s2323. It says a reset during EEPROM write will corrupt data at the address written to and address 0.
That could almost explain the symptom I see, if I write to EEPROM a lot more often than I think I do.
Still, this is not mentioned in the tiny26 datasheet, and the problem go away when I set the address to 2..127.

Guess I should verify how often my EEPROM writes are executed.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thomas Strand wrote:

That could almost explain the symptom I see, if I write to EEPROM a lot more often than I think I do.

If this happen, then this ist the fault in your code.

If you write permanently to the EEPROM, then the life time should be over after some hours.

You must change the code, that a write was only initiated by the user (hit a key) and if different to the current content.

On my applications I have also implemented, if the user hit the key twice, the next write was delayed by 10 seconds.

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes of course, I don't write to EEPROM constantly. That's once about five seconds after last keypress.
I will verify this tomorrow, it's getting late here in Norway.

Maybe I am wearing out the EEPROM, one byte at a time?
Should be able to find the bug before all are lost :lol:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

i am facing similar problem with ATmega8535L

The initial problem was with first 5 to 6 bytes but i realized i was not using and brown out protection

after using brownout protection at 4 V problem reduced to first 2-3 bytes

Workaround as suggest, was to use different memory address. So in all my applications involving avr and EEPROM i have an ofset of 10 bytes for my EEPROM.

But the basic problem still exist.....

Regards, Kapil +) ISP lines on MEGA128 NOT mapped on SPI +) Tiny4/5/9/10, Isolate Reset line from ISP before connecting it to +12V

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just found out I did write to the EEPROM more often than I thought :oops:
About once per 5 seconds. I would reach 100 000 writes after about 139 hours, or 5.8 days.

So I'm officially on address 3 8)

kapilsinghi:
Guess you should make sure you're not writing the guts out of your EEPROM too :)

I connected a logic analyzer to a pin on the AVR and modified the code to set this pin high just before the EEPROM write, and low just after the write. There was a 3.5µs pulse every ~5 seconds, not what I expected.

Guess I found the cause of my problem. Still not entirely sure about address 0, though. I don't think it ever worked correctly, but then again, I'm not 100% sure.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thomas

I am not writing too eeprom this frequentely

I write to eeprom

save it

after delay of 10 seconds switch off the power

after some 5 seconds switch on the power

check the eeprom value and found that it is corrupted

Regards, Kapil +) ISP lines on MEGA128 NOT mapped on SPI +) Tiny4/5/9/10, Isolate Reset line from ISP before connecting it to +12V