Searching \ for '[AVR] ATMega128 EEPROM corruption' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/mems.htm?key=eeprom
Search entire site for: 'ATMega128 EEPROM corruption'.

Exact match. Not showing close matches.
PICList Thread
'[AVR] ATMega128 EEPROM corruption'
2006\06\27@180206 by Mike Hord

picon face
Has anyone seen/heard of ATMega128s spuriously
erasing EEPROM contents?

We're seeing a small but increasing number of
instances of erases (or at least, rewrites to $FF).
The number is too small for us to be certain of a
pattern in locations, but so far we have at a minimum
two distinct locations which have been erased,
possibly three (it's hard to know for certain because
two of the examples have had an erase occur in
a memory location which triggers a rewrite of a
large portion of the EEPROM, including those
four bytes, which hides the evidence).

Nothing in the errata; I'm on my way to the
AVRFreaks forum to check out what they have
to say.

The chip is protected by a supervisory chip which
keeps it in reset below 2.9V- it should be good
to operate down to 2.7V.

Mike H.


'[AVR] ATMega128 EEPROM corruption'
2006\08\09@170407 by Mike Hord
picon face
So, it turns out that the ATMega128 seems to be quite susceptible
to the EEPROM address 0 correction bug which has plagued
Atmel in the past.  Atmel just hasn't acknowledged it, or deemed
it fit information to put into their errata.

This was my first real foray into Atmel-land, and I gotta say, I don't
like what I've seen.  The programmer (JTAGICE mk II) that I
started out with has gone stupid on me (it still communicates, but
I can't get it to actually work with a chip)(I think it may be that
crappy under-robust ribbon cable they give you with it), my company
spent many hours of engineering time and customer goodwill
hunting down a problem which SHOULD be in the errata but isn't,
and which Atmel didn't tell me about when I asked them, specifically,
whether it might be an issue, and when I finally DID get a programmer
working, I'm finding that programming multiple boards seems to
require reconnecting to the programmer between each one.

Add in their reputation (as I've heard) for discontinuing parts at an
above-average rate, for supply chain issues, and the news Russell
posted, and I think I'll stick with Microchip.

Of course, my employer has thrown THEIR hat in Atmel's ring...

Mike H.

2006\08\09@172428 by John Samperi

picon face
At 07:04 AM 10/08/2006, you wrote:
>Add in their reputation (as I've heard) for discontinuing parts at an
>above-average rate,

True, but I have found that they seem to always have a
pin and mostly code compatible (very small changes if any)
chip which is cheaper than the one it replaces and it has more
features. This was the main reason for me to ditch Motorola
after many many years of use.


Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495       Fax (02) 9674-8745
Email: spam_OUTjohnTakeThisOuTspamampertronics.com.au
Website  http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************

2006\08\09@175233 by David VanHorn

picon face
On 8/9/06, Mike Hord <.....mike.hordKILLspamspam@spam@gmail.com> wrote:
>
> So, it turns out that the ATMega128 seems to be quite susceptible
> to the EEPROM address 0 correction bug which has plagued
> Atmel in the past.  Atmel just hasn't acknowledged it, or deemed
> it fit information to put into their errata.


How did you ascertain that?

I have, for many years, left location 0 as a "sacrificial goat", with the
EEAR pointing there on exit from any read or write, so that any accidental
operation would not corrupt my data.

Years past, I wrote some firmware for the 8515 specifically looking for any
EE corruption, and never did find any.

People frequently miss some of the constraints of modifying EE or codespace,
and think that there is a chip problem, when there is not.
Things like when power dissapears, and when reset can occur..

2006\08\09@180840 by John Samperi

picon face
At 07:52 AM 10/08/2006, you wrote:
>People frequently miss some of the constraints of modifying EE or codespace,
>and think that there is a chip problem, when there is not.
>Things like when power dissapears, and when reset can occur..

....or not having BOD enabled, not having interrupts disabled while writing
to the eeprom, not having the CKOPT enabled for frequencies above 8 MHz...
oh you fell for that too David IIRC :)....



Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495       Fax (02) 9674-8745
Email: johnspamKILLspamampertronics.com.au
Website  http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************

2006\08\09@185222 by Mike Harrison

flavicon
face
On Thu, 10 Aug 2006 07:23:52 +1000, you wrote:

>At 07:04 AM 10/08/2006, you wrote:
>>Add in their reputation (as I've heard) for discontinuing parts at an
>>above-average rate,
>
>True, but I have found that they seem to always have a
>pin and mostly code compatible (very small changes if any)
>chip which is cheaper than the one it replaces and it has more
>features.

..and just for fun they throw in the occasional extremely subtle change that takes forever to
find...

Original product used 90S4414. When this went obsolete, changed to 90S8515. Then this went obsolete,
changed to tiny8515, which exhibited  wierd behaviour similar to eeprom corruption, but the whole
eeprom appeared to be getting lost.

After a week or so of head-scratching, figured it out :
90S4414 has 256 bytes eeprom, so no high-order address bit.
90S8515 has 512 bytes eeprom, but high-order address bit initialises to 0 on reset.
Mega8515 does not initalise high-order address bit on reset, so random eeprom page selected....

One thing that made this harder to figure out was our product had a 2200uf cap across the 5V rail to
keep a couple of  RC servos happy. This meant that  you could leave it powered off for an hour or
two after programming & it would coem back on  fine, A few hours longer (i.e. after shipping to
customer) and it would fail.




2006\08\09@193514 by Sean Schouten

face picon face
On 8/9/06, David VanHorn <.....dvanhornKILLspamspam.....microbrix.com> wrote:
>
>
> Years past, I wrote some firmware for the 8515 specifically looking for
> any
> EE corruption, and never did find any.
>
>
What's the story with the EEPROM memory in microchip MCUs and data being
corrupted? I read a a considerable amount on this list about people using a
*best of three* algorithm to confirm that data has not been corrupted and
then refresh what is. Am I right to assume that this is not needed in an
Atmel (except to be sure in case of some real mission critical application)
because they don't experience the same problem?

Thanks,

Sean.

2006\08\09@194348 by Michael Dipperstein

face
flavicon
face
The EEPROM address 0 is indeed a problem in some older Atmel parts.
I've actually received confirmation of the problem from the local FAE.
I've also received confirmation that it's not a problem with the
ATmega48/88/168 series.

Apparently, there are some processors that have registers set to cause
an EEPROM write to byte 0 as they power-up.  Once you get past the
power-up sequence, EEPROM byte 0 is safe to use.

To avoid this problem, the IAR and ImageCraft C compilers will not
allocate EEPROM data to byte 0.  Unfortunately, both compilers do this
independent of the processor type.

-Mike

> From: EraseMEpiclist-bouncesspam_OUTspamTakeThisOuTmit.edu [piclist-bouncesspamspam_OUTmit.edu] On
Behalf
{Quote hidden}

the
> EEAR pointing there on exit from any read or write, so that any
accidental
> operation would not corrupt my data.
>
> Years past, I wrote some firmware for the 8515 specifically looking
for
> any
> EE corruption, and never did find any.
>
> People frequently miss some of the constraints of modifying EE or
> codespace,
> and think that there is a chip problem, when there is not.
> Things like when power dissapears, and when reset can occur..
> -

2006\08\09@235200 by David VanHorn

picon face
>
>
> ....or not having BOD enabled, not having interrupts disabled while
> writing
> to the eeprom, not having the CKOPT enabled for frequencies above 8 MHz...
> oh you fell for that too David IIRC :)....


Yes, and so have a LOT of people.
FWIW, it dosent' matter what frequency you're running at either.
The vittoz mode osc output is only about 0.5VCC, and unless the crystal is
selected for very small cap values and the whole ckt has been carefully
designed, you'll have problems.

2006\08\11@153435 by Michael Rigby-Jones

picon face


>-----Original Message-----
>From: KILLspampiclist-bouncesKILLspamspammit.edu [RemoveMEpiclist-bouncesTakeThisOuTspammit.edu]
>Sent: 10 August 2006 04:52
>To: Microcontroller discussion list - Public.
>Subject: Re: [AVR] ATMega128 EEPROM corruption
>
>
>>
>>
>> ....or not having BOD enabled, not having interrupts disabled while
>> writing to the eeprom, not having the CKOPT enabled for frequencies
>> above 8 MHz... oh you fell for that too David IIRC :)....
>
>
>Yes, and so have a LOT of people.
>FWIW, it dosent' matter what frequency you're running at
>either. The vittoz mode osc output is only about 0.5VCC, and
>unless the crystal is selected for very small cap values and
>the whole ckt has been carefully designed, you'll have problems.

FWIW I didn't have the CKOPT bit selected on a whole bunch of engineering devices running with a 7.3728MHz resonator, and never experienced any issues that I could relate to the clock.  Better safe than sorry though.

Also I did experience numerous EEPROM corruption problems, which was down to my own ignorance.  I had selected a suitable brown out voltage in the configuration fuses, but hadn't actualy enabled the brown out reset!  Once done, all EEPROM issues were magicaly resolved.  I also have location 0 as a sacrificial lamb, if you can spare the one location I think it's a worthwhile precaution.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2006\08\11@164256 by David VanHorn

picon face
>
>
> FWIW I didn't have the CKOPT bit selected on a whole bunch of engineering
> devices running with a 7.3728MHz resonator, and never experienced any
> issues that I could relate to the clock.  Better safe than sorry though.


I'd shipped a whole bunch before we discovered this little feature.
One sneaky indicator, is that the baud rate is sometimes a little wrong,
maybe 1% or so, but using a baud rate xtal, there shoud be no measurable
error.

Also I did experience numerous EEPROM corruption problems, which was down to
> my own ignorance.  I had selected a suitable brown out voltage in the
> configuration fuses, but hadn't actualy enabled the brown out reset!  Once
> done, all EEPROM issues were magicaly resolved.  I also have location 0 as a
> sacrificial lamb, if you can spare the one location I think it's a
> worthwhile precaution.


I've done this on a lot of platforms, way before atmel. That register always
points SOMEWHERE..  Sometimes you can point it to illegal spaces, but that
may not be all that safe either.

More... (looser matching)
- Last day of these posts
- In 2006 , 2007 only
- Today
- New search...