Continuous write of same value to eeprom

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

Using IAR Embedded Workbench, and ATMega128.

If I continuous write the same value to the same eeprom location, does it kill the eeprom?

E.g.
Uint8 __eeprom eeVar;
while(1)
{
eeVar = 0xA5;
}

(Of course i'll never actually use the above code. But just as an illustration) :)

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

You compile the code.
You enter C-SPY. (or Studio)

You look for yourself at the ASM code.

The same approach applies to any compiler. After all, if someone gave you the answer, you would only believe them when you have seen for yourself.

And if you wear braces with your belt, you can always read the current value yourself, before choosing to write.

David.

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

Quote:

If I continuous write the same value to the same eeprom location, does it kill the eeprom?

Theory would suggest after 100,000 iterations of the while(1) it may have damaged the EEPROM location where eeVAr is stored.

HOWEVER it could be that IAR is as smart as Codevision (or the eeprom_update_byte() routines in GCC) and does not bother to write a value that is the same as the one already stored (it does a read/compare before write as it's much quicker than writing). If this is the case then that code may only actually write the location once. However:

while(1) 
{ 
  eeVar = 0xA5; 
  eeVar = 0x5A; 
}

almost certainly would destroy the EEPROM location.

You need to look at the generated Asm and see whether IAR is doing such a smart read/check/write rather than just write.

(as this thread has nothing to do with GCC I'll move it from GCC to AVR Forum)

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

In all my code that stores a value to eeprom I always first read the current value and compare it to the new value before writing to the eeprom. I never thought the (GCC) library write routine would perform this check. Actually I think that the eeprom probably doesn't wear out writing ones, only zeros since the one state is the 'erased' state.

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

Quote:

I never thought the (GCC) library write routine would perform this check.

Until recently it didn't and eeprom_write_[byte/word/dword]() still don't but the recent release of eeprom.h (contained in WinAVR20100110) now has eeprom_update_[byte/word/dword/float]() added and these routines do a read check.

As for wear, you are probably right. If you wrote a location 0xFF, 0xFE, 0x3E, 0x1C, 0x08, 0x00 then it *might* be the case that the AVR is smart enough to recognise that at each step there are only 1->0 transitions so a cell erase is not required. But I don't know if the AVR itself is that smart?

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

Eeprom does an erase-write cycle. So I would guess it will wear very fast.

No. I do not know about IAR. But no doubt ccheung wil tell us.

David.

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

Quote:

But no doubt ccheung wil tell us.

Pre-empting that:

     14              eeVar = 0xA5; 
   \   00000000   EA05               LDI     R16, 165
   \   00000002   ....               LDI     R20, LOW(eeVar)
   \   00000004   ....               LDI     R21, (eeVar) >> 8
   \   00000006   ........           CALL    __eeput8_16

I can't work out how to get an asm listing of __eeput8_16 but according to the Studio disaassembler:

@0000004D: __eeput8_16
+0000004D:   B60F        IN        R0,0x3F        In from I/O location
+0000004E:   DFF2        RCALL     PC-0x000D      Relative call subroutine
+0000004F:   BB0D        OUT       0x1D,R16       Out to I/O location
+00000050:   CFF5        RJMP      PC-0x000A      Relative jump

0x1D in that is EEDR on the mega16 I built for. The first call that makes is:

+00000041:   99E1        SBIC      0x1C,1         Skip if bit in I/O register cleared
+00000042:   CFFE        RJMP      PC-0x0001      Relative jump
+00000043:   9508        RET                      Subroutine return

which is checking the EEWE bit in EECR. The final RJMP is to:

+00000046:   BB4E        OUT       0x1E,R20       Out to I/O location
+00000047:   BB5F        OUT       0x1F,R21       Out to I/O location
+00000048:   94F8        CLI                      Global Interrupt Disable
+00000049:   9AE2        SBI       0x1C,2         Set bit in I/O register
+0000004A:   9AE1        SBI       0x1C,1         Set bit in I/O register
+0000004B:   BE0F        OUT       0x3F,R0        Out to I/O location
+0000004C:   9508        RET                      Subroutine return

which is outputting the EEPROM location to EEARH/EEARL then setting bits EEMWE followed by EEWE in EECR.

So, no, IAR is making no attempt to avoid writing the same value with a check read.

Cliff

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

Thanks a lot for your help, guys.

I tried to look through the ASM output as david.prentice suggested, but got lost in there...

So thanks to clawson for helping me wade through that.

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

Thanks also to clawson from me too!

So if you are a belt and braces type of person, you do your own read, and write if different.

Ideally, you design your program in the first place. i.e. you cope with the worst case and make sure that the endurance spec will never be exceeded.

Most uses of EEPROM are for configuration that rarely changes during the lifetime of a product. Even human beings have a limit on how often they want to change a configuration.

David.

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

Hi,

For a simple update of a configuration variable that doesn't change often, the 100k design limit seems very large.

But, for a value or state that is constantly changing that you need to save on a short time period, it can be an issue.

I developed a project called EEPROM structure library that will do a round robin approach to saving eeprom data to multiple locations in eeprom to increase the time it takes before hitting the 100k limit. It also saves the data twice in case of corruption, uses a crc16 to validate the data, and automatically reads from the latest copy that has integrity.

Good luck,

Alan