Yahoo Groups archive

AVR-Chat

Index last updated: 2026-04-28 22:41 UTC

Thread

Re: [AVR-Chat] RE: ATmega88PA EEPROM Memory Life

Re: [AVR-Chat] RE: ATmega88PA EEPROM Memory Life

2012-12-12 by Clark Martin

On Dec 12, 2012, at 2:04 PM, Benny Smith wrote:

> The Mega88PA data sheet gives the EEPROM a write/erase lifetime of 100,000
> cycles.
> 
> I assume that this applies byte-by-byte to the EEPROM contents.
> 
> In other words, I assume that if only one of the 88PA's 512,000 EEPROM bytes
> is changed, then only that byte (i.e., its 8 memory-bit locations) has used
> up one of its 100,000 cycles.
> 
> All other EEPROM bytes, which were not changed, still have their full
> lifetime of 100,000 cycles available.
> 
> So, if I wanted to save a byte frequently, I could use up the 100,000 cycles
> at one byte address and then switch to another byte address to store the
> next 100,000 repetitions of my byte-save operation.
> 
> Is that correct?

Yes.  You'd either want to use another byte(s) location to indicate which EEPROM location has the current data or find out what the excessive writing failure mode is (0 or 1) then when the current location is worn out and it fails to pass a verification read then write it to either all 0s or all 1s and put the data in the next location in sequence.  0x00 or 0xFF would need to be reserved and not represent actual data.

[Non-text portions of this message have been removed]

Re: [AVR-Chat] RE: ATmega88PA EEPROM Memory Life

2012-12-13 by Bob Paddock

> Yes. You'd either want to use another byte(s) location to indicate which
> EEPROM location has the current data or find out what the excessive writing
> failure mode is (0 or 1) then when the current location is worn out and it
> fails to pass a verification

Another failure is where it will verify immediately after writing, but will lose
charge over time.  Time could be measured in seconds or days in this case.
An immediate read back is not an indication of a good write to EEPROM
cells that are dieing.

At room temperature you may get millions of write cycles to a
location.  8 Million is the case I'm familiar with.
Data sheet does not say 100,000 is the maximum it says it is the
guaranteed minimum.
It is not going to fail at 100,001.

I've gotten inconsistent answers from Atmel over the years about
EEPROMs wearing at the byte or the page level.
Look at the section on memory programming and it will give the EEPROM
page size.  4 and 16 bytes are typical EEPROM page sizes.
I've always gone conservative and assumed EEPROM wears by pages.  Can
someone point to a definitive Atmel answer?

There are techniques for increasing EEPROM life such as using Gray
Code to store your EEPROM data.  Fewer number of bits will transition
with a given write.
There is also inverted one-hot code; shift a single zero bit around,
EEPROM has no penalty for writing ones.


--
http://blog.softwaresafety.net/
http://www.designer-iii.com/
http://www.wearablesmartsensors.com/

bypass caps

2013-01-03 by Steven Hodge

I am moving from a DIP package for a Mega644P to the TQFP-44 package.  Am I
correct that a separate bypass cap should be on *each* Vcc pin (and AVcc and
AREF)?   Thanks, Steve



[Non-text portions of this message have been removed]

Re: [AVR-Chat] bypass caps

2013-01-03 by Martin McKee

Steve,
That is correct.  As a general rule, have a cap per Vcc pin.  In addition,
depending upon upon your analog requirements, you may want to low-pass
filter the analog pin.

Martin Jay McKee

On Wed, Jan 2, 2013 at 7:24 PM, Steven Hodge <steve@terrafirma.us> wrote:

> **
>
>
> I am moving from a DIP package for a Mega644P to the TQFP-44 package. Am I
> correct that a separate bypass cap should be on *each* Vcc pin (and AVcc
> and
> AREF)? Thanks, Steve
>
> [Non-text portions of this message have been removed]
>
>  
>


[Non-text portions of this message have been removed]

Re: [AVR-Chat] bypass caps

2013-01-03 by Leon Heller

On 03/01/2013 02:24, Steven Hodge wrote:
> I am moving from a DIP package for a Mega644P to the TQFP-44 package. Am I
> correct that a separate bypass cap should be on *each* Vcc pin (and AVcc and
> AREF)? Thanks, Steve

Yes.

Leon
-- 
Leon Heller
G1HSM

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.