avr-chat
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-chat] AVR EEPROM cell: Does 0xff mean it it is erased?


From: Rogier Wolff
Subject: Re: [avr-chat] AVR EEPROM cell: Does 0xff mean it it is erased?
Date: Wed, 21 Oct 2009 13:38:58 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

On Sun, Oct 18, 2009 at 11:17:26AM +0200, Heike C. Zimmerer wrote:
> do nothing if they match, do a full erase/write if they differ, and do a
> write-only if the cell contains 0xff, I could go on without increasing
> the time needed for powering down.  Of cause, this only works if 0xff in
> a cell means it doesn't need to be erased.

Have you noticed that the datasheet specifies a wide margin for the
programming times of eeprom cells? (or only a max, no min?)

Internally writing an eeprom/flash cell seems to work like:

   for (i=0;i<MAX;i++) {
      program_cell_1_cycle (addr, value); 
      if (read_cell (addr) == value)
        break;
   }
   if (i == MAX) return ERROR; 
   n = i;

   for (i=0;i<n;i++) {
      program_cell_1_cycle (addr, value); 
   }

In the old days you had to execute this algorithm for programming
certain chips.

A normal cell may require say 33 loops in the first loop, so 99 
times through the second loop for a total of 132 programming cycles.

If you try to program 0x55, it may still read as 0xff for 30 cycles, 
switch to 7f, 5f, 57, 55 over the next three cycles. 

So if programming a location failed because of a powerdown, it might
still read as 0xff after 28 cycles. Then power goes down. Next time
you start up, you read 0xff, and conclude that it's still empty. This
algorithm would then find that after 7 cycles the correct value of
0x55 is present, and then run the second loop 21 times. In the end
your location got only 56 cylces of programming instead of the
intended 132. (in the short run, your cell WILL read as 0x55 for a
while.  But it may creep back to another value between 0x55 and 0xff 
over time or under different circumstances!)

Anyway, I'm not sure it still works like that. Maybe that the AVR
guarantees writing of the location once you start it. Maybe you can
provide the environmnent where you won't initiate an eeprom write 
when power is going down "soon". 

        Roger. 

-- 
** address@hidden ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ




reply via email to

[Prev in Thread] Current Thread [Next in Thread]