Mega324P eeprom forgettery

Log in or register to post comments
Go To Last Post
9 posts / 0 new
Author
Message
barnacle
barnacle's picture
Level: Raving Lunatic
Joined: Tue. Jan 3, 2006
Posts: 5920 View posts
Location: Hemel Hemsptead, UK
#1
Posted by barnacle: Sun. Mar 29, 2009 - 07:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is the M324's eeprom known to have the same issues as M32? As in, forgetting the value in eeprom address zero at random intervals, particularly at low voltages?

I have the following code:

char engine_type __attribute__ ((section(".eeprom")));
char display_mode[4] __attribute__ ((section(".eeprom")));

as the first and only definitions to the eeprom. Elsewhere, my code compares engine_type for a sane value and resets display_mode to sane values if it doesn't find them.

In the previous version, (M32 at 3.3v) I used the brownout detector at 2.7v to keep the chip in reset until the power got happy and that made the issue go away.

I find I have accidentally programmed a couple of M324 units with the BOD disabled; one worked fine for a week and then reset itself today and one reset itself every time it is turned on.

Ho hum...

Neil

Neil Barnes
www.nailed-barnacle.co.uk

Tags:

AVR Microcontrollers, megaAVR and tinyAVR
Top
theusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 39690 View posts
Location: Wisconsin USA
Posted by theusch: Sun. Mar 29, 2009 - 10:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, given that I count on EEPROM to hold values in all of my production apps, I would never use the word "random". And probably not "forget" either.

Quote:

at low voltages?

Certainly! When you drop power the AVR is still running, trying like a steer. At some point certain parts stop functioning. (Reminds me of a shot-up robot in a sci-fi film.) And some of those are the EEPROM address bus. There have been reports of corruption even in AVRs that have no EEPROM reads. From that we can gather that the EEWE bit chan change just as easily as EEAR.

I have not tried like a masochist to force the problem in Mega164/324/624 but I'd assume the situation exists when running below spec. It certainly does on Mega64 and Mega640 and Mega48/88 and Mega48P/88P.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Top
barnacle
barnacle's picture
Level: Raving Lunatic
Joined: Tue. Jan 3, 2006
Posts: 5920 View posts
Location: Hemel Hemsptead, UK
Posted by barnacle: Mon. Mar 30, 2009 - 09:18 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Lee; that's what I had concluded. I'll play further...

Neil Barnes
www.nailed-barnacle.co.uk

Top
theusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 39690 View posts
Location: Wisconsin USA
Posted by theusch: Mon. Mar 30, 2009 - 01:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

NB: For what it is worth, we happen to have one of our apps set up in a power-cycling test mode: Power on; one app cycle; power-off.

There are "modules" with AVRs that communicate with a "master" AVR. Mega64 master; a total of 6 slaves with 2x Mega162, 2x Mega88, 2x Mega48.

We are up to 10000 power cycles. That is equivalent to one a day for ~30 years, or one an hour for a year+ 24/7.

Every time it starts up, all the configuration information is read from EEPROM of the various AVRs. While certainly some bits may be benign, in general the app will not cycle properly without the proper configuration. By this time, I would certainly have noticed if one or more AVRs in this system had "randomly" "forgot" any EEPROM information.

Admittedly, this is one setup of the control system running under "bench" conditions. But this app has been shipping 100+/month for 3+ years; latest serial number is 5134. So that is 25000+ AVRs all with configuration information in EEPROM. You'd think I'd hear about it, long and loud, if there was any amnesia.

That is one production app. Over the years there are dozens more. Most are in an industrial environment, with motors, and contactors, and relays, and transformers, and the like. Those don't forget either, or the timers wouldn't time right, and the counters wouldn't count right, and the dispensers wouldn't measure correctly, and the chemical concentration would be off, and the temperatures would be too high or too low, and ...

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Top
barnacle
barnacle's picture
Level: Raving Lunatic
Joined: Tue. Jan 3, 2006
Posts: 5920 View posts
Location: Hemel Hemsptead, UK
Posted by barnacle: Tue. Mar 31, 2009 - 09:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Setting the BOD to 2.7v appears to have resolved the issue; I'm running a few days tests now to make sure it's disappeared.

I use a long reset, but it seems that even so the rail may have been rising too slowly for the chip to work reliably in that first 'read the eeprom config' phase.

Let's see how it goes.

Neil

Neil Barnes
www.nailed-barnacle.co.uk

Top
theusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 39690 View posts
Location: Wisconsin USA
Posted by theusch: Tue. Mar 31, 2009 - 01:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I use a long reset, but it seems that even so the rail may have been rising too slowly for the chip to work reliably in that first 'read the eeprom config' phase.

AFAIK the problem occurs with corruption occurring during power-down. But I guess it could just as easily happen with rising power taking the AVR out of reset but not yet enough voltage for the EEPROM to work properly.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Top
KKP
KKP's picture
Level: Resident
Joined: Tue. Jun 26, 2001
Posts: 848 View posts
Location: Silkeborg, Denmark
Posted by KKP: Tue. Mar 31, 2009 - 04:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Both at power up and power down is my experience.
At power up you usually have more time to get to a usable VCC since there's the always-active POR which gives you some extra time (60ms? default) before execution starts. If VCC rises slowly enough, the micro attempts to execute code, is running out of spec, and does crazy things. Same on power down, though it's much easier to hit since the micro is already running.
If you test your equipment against the European e-mark requirements for automotive electronic devices, you WILL see this since one of the tests simulates a slow battery charge and discharge. Even if one doesn't do automotive, it's a good test to run.

One thing to look out for even when using proper undervoltage reset is eeprom read on powerup: If you set the POR delay to something short, like 2ms, your program starts a write, vcc dips below the limit for <1ms, 2ms later the cpu comes out of reset, and attempts to read an eeprom cell. One might think that the eeprom won't ever be busy after reset, but in the above example EEWE is still set, and a read without waiting for the write to complete produces invalid data. VCC needs to dip really far down for the eeprom to terminate the write, it appears.

On AT90S8515 and brethren (ie. not M32) the EEAR register would reset to zero on reset. This meant that if your program started a write, the eeprom started writing, and reset happened, it would change the address with the write drivers hot, causing if not death, then destruction and gnashing of teeth.

/Kasper

Top
theusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 39690 View posts
Location: Wisconsin USA
Posted by theusch: Tue. Mar 31, 2009 - 05:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

your program starts a write, vcc dips below the limit for <1ms, 2ms later the cpu comes out of reset, and attempts to read an eeprom cell. One might think that the eeprom won't ever be busy after reset, but in the above example EEWE is still set, and a read without waiting for the write to complete produces invalid data. VCC needs to dip really far down for the eeprom to terminate the write, it appears.

Isn't there a notation in recent AVR generation datasheets that an EE write is finished before reset? Hmmm--can't seem to find it.

At startup of my AVR apps, I do preliminary init (after the C prologue) to set pin directions on my ports, then invoke a delay as long as the app can stand. Typical values are 100ms to 250ms. That, coupled with the BOD should avoid most of the ugly situations.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Top
KKP
KKP's picture
Level: Resident
Joined: Tue. Jun 26, 2001
Posts: 848 View posts
Location: Silkeborg, Denmark
Posted by KKP: Tue. Mar 31, 2009 - 06:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ATMega16 datasheet:

Quote:
If a reset occurs while a write operation is in progress, the write
operation will be completed provided that the power supply voltage is sufficient

No. Reset happens regardless of a write being in progress, and the eeprom write continues regardless of reset. The best way to think of it is the eeprom being independent and not having reset as an input.

/Kasper

Top