AVR EEPROM cell: Does 0xff mean it it is erased?

[Heike C. Zimmerer-6]

Hello,

can I safely assume that if an EEPROM cell contains 0xff, it doesn't
need to be erased before writing to it?

Most newer AVRs offer the possibility to split erase and write to EEPROM
into two separate tasks, each of them taking about half the execution
time.  Now let's assume I write some state data (12 bytes each) into
consecutive locations (ring buffer) every, say, 5 minutes.  Under normal
conditions, there's no need to separate the tasks, but I do it anyway
(for reasons explained later) and I can make sure the next location
has been previously erased when it is written to.

However, when an external power down interrupt occurs, I need to write
the same data as fast as possible.  Under normal circumstances, I know
where to write to and I know the area has been erased before so I can
use the faster write-only cycle and skip erase.

Things change when the power down INT occurs while the main program is
writing a record (i.e., the INT falls exactly into a small time slot of
22 ms every 5 minutes).  Then I don't know which part of the record
already has been written out (I could keep track of but currently I hope
I don't need to) and I need to write to the same area again.

I can safely assume at most 4 of the 12 bytes will differ from what the
main program was just trying to write, so - my idea which needs to be
verified - if I compare the contents of the cells against the new data,
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.

Then there was this problem with earlier AVRs where an erased cell would
read 0x0 at low voltages, but - if I remember correctly - read 0xff when
previously having been written to with 0xff.  I don't know for sure if I
remember this correctly.  This may indicate that there is a difference
between being erased and being written to with 0xff.

Does anybody know more about that?  As an illustration, I include the
current untested draft of the EEPROM write function:

----------------------
/*C
   void eeprom_write_byte_fast(uint8_t *eeaddr, uint8_t data);

   /# Write a byte to a (most possibly) erased ee-cell (faster than normal
   write if the area has been erased previously).
   
   If the cell is not yet erased, add erase cycle.  If the cell already
   contains the target data, return immediately. #/
*/
              .global eeprom_write_byte_fast
eeprom_write_byte_fast:
              sbic  _SFR_IO_ADDR(EECR),EEPE
              rjmp  eeprom_writeNE_byte ; eeprom not yet ready
              out   _SFR_IO_ADDR(EEARH),r25
              out   _SFR_IO_ADDR(EEARL),r24 ; set addr
              sbi   _SFR_IO_ADDR(EECR),EERE ; get current contents of the cell
              in    r23,_SFR_IO_ADDR(EEDR)
              cpi   r22,r23         ; already same?
              breq  ewRet           ; yes.  Nothing to do.
              out   _SFR_IO_ADDR(EEDR),r22 ; set data
              ldi   r20,1<<EEPM1|1<<EEMPE ; assume write only
              cpi   r23,0xff        ; is cell really erased already?
              breq  ewWriteNow      ; yes
              ldi   r21,1<<EEMPE    ; No.  Do a full erase/write cycle
ewWriteNow:   in    r21,_SFR_IO_ADDR(SREG) ; save INT flag
              cli
              out   _SFR_IO_ADDR(EECR),r20
              sbi   _SFR_IO_ADDR(EECR),EEPE ; start writing
              out   _SFR_IO_ADDR(SREG),r21 ; restore INT flag
ewRet:        ret
----------------------


Thanks,

Heike



_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Joerg Wunsch]

"Heike C. Zimmerer" <lists@...> wrote:

> can I safely assume that if an EEPROM cell contains 0xff, it doesn't
> need to be erased before writing to it?

Yes, you can.  Programming flash or EEPROM cells always goes from '1'
to '0', so a cell containing all '1' is erased.

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[David Kelly]

On Oct 18, 2009, at 7:55 AM, Joerg Wunsch wrote:

> "Heike C. Zimmerer" <lists@...> wrote:
>
>> can I safely assume that if an EEPROM cell contains 0xff, it doesn't
>> need to be erased before writing to it?
>
> Yes, you can.  Programming flash or EEPROM cells always goes from '1'
> to '0', so a cell containing all '1' is erased.

IIRC only Freescale HC12 flash erases to 0. At least thats the only I  
have encountered.

--
David Kelly N4HHE, dkelly@...
========================================================================
Whom computers would destroy, they must first drive mad.





_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Bob Paddock]

> IIRC only Freescale HC12 flash erases to 0. At least thats the only I have
> encountered.

Some serial EEPROMs, at least old Xicor ones, erased to 0xFF but as
shipped from the factory they contained a "checker board" pattern.  Looked more
like junk when doing a read, because the rows and columns were
physically different
than what you would logically expect.

I asked the Xicro factory about that, and they set it was to expedite their
test times.  Ever since I've never made the assumption a new factory part
comes in the erased state, unless that is explicitly mentioned in the
data sheet,
of any programmable part.


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Weddington, Eric]

 

> -----Original Message-----
> From: avr-chat-bounces+eric.weddington=atmel.com@...
> [mailto:avr-chat-bounces+eric.weddington=atmel.com@...]
>  On Behalf Of Bob Paddock
> Sent: Sunday, October 18, 2009 7:16 AM
> To: avr-chat@...
> Subject: Re: [avr-chat] AVR EEPROM cell: Does 0xff mean it it
> is erased?
>
> > IIRC only Freescale HC12 flash erases to 0. At least thats
> the only I have
> > encountered.
>
> Some serial EEPROMs, at least old Xicor ones, erased to 0xFF but as
> shipped from the factory they contained a "checker board"
> pattern.  Looked more
> like junk when doing a read, because the rows and columns were
> physically different
> than what you would logically expect.

Wow. That's a bit strange.
 
> I asked the Xicro factory about that, and they set it was to
> expedite their
> test times.  Ever since I've never made the assumption a new
> factory part
> comes in the erased state, unless that is explicitly mentioned in the
> data sheet,
> of any programmable part.

Very good point.


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Heike C. Zimmerer-6]

j@... (Joerg Wunsch) writes:

> Yes, you can.  Programming flash or EEPROM cells always goes from '1'
> to '0', so a cell containing all '1' is erased.

Thanks.

Heike


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[rew]

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.

--
** R.E.Wolff@... ** http://www.BitWizard.nl/ ** [phone] **
**    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


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat