Losing EEPROM value after a few days

Go To Last Post
29 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This one is so weird I assume I'm doing something wrong (in large part because I haven't worked with eeprom on the AVR before).

I've got a couple of configuration values in eeprom (ATmega48P), and after a day or two unpowered many units have lost the values. At this point my code does not write to eeprom, only reads from it. I write the eeprom by downloading the .eep file from AVR Studio.

Here are the relevant code snips:

Initializing in source:

uint8_t	EEMEM EE_device_addr = 3;

Reading back on code startup:

Device_addr = eeprom_read_byte( &EE_device_addr );

From the map file:

.eeprom         0x00810000        0x2
 *(.eeprom*)
 .eeprom        0x00810000        0x2 globals.o
                0x00810001                EE_frame_cnt
                0x00810000                EE_device_addr
                0x00810002                __eeprom_end = .

The code compiles without error or warning, and it always runs correctly after I program the devices. It's only when I turn on the units a few days later that some have lost their configuration values, replaced with random values such as 0x1D, 0xEE, 0xFC, 0xFF.

FWIW, of the two configuration values I'm setting, the first is always trashed when I read back from bad units, while the second was only trashed in one unit.

Any ideas?

Mike

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you have the BOD enabled? If not, enable it and see if it helps.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you have the BOD turned on?

If you check one of these units that is prone to EEPROM data loss after a shorter off time (a few hours, 12 hours, a day, etc), what do you find?

Address 0x0000 has had historic problems, as recall. This was, I think, largely solved by using the BOD. But, many still do not write anything to that address.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you using a bootloader? Maybe you get a power glitch and the bootloader erases flash, and sits there waiting for the new program to start coming down the wire?

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not only 0x00 address, but without BOD, most of the eeprom gets washed out.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is very interesting. So without BOD enabled, eeprom that has been correctly written may be corrupted later? What is the mechanism for this? Maybe I should ask, how can Atmel sell such devices?

FWIW, I'm using a 6A supply for Vcc, and probably not drawing more than 200mA worst case. But I'm going to read up on BOD and eeprom for sure.

Mike

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

yellowboy_75 wrote:
Not only 0x00 address, but without BOD, most of the eeprom gets washed out.

Not quite true. Not having BOD disabled does not corrupt the EEPROM directly, or more of it. Having said that, any byte in EEPROM is equally susceptible to corruption, not just address 0. Enabling the BOD prevents your code from mis-executing, as a result of a brown-out condition, thus causing the corruption. The corrupted byte[s] will be a result of whatever is currently in the EEPROM address register when the brown-out occurs.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Below is what CodeVisionAVR support suggest regarding eeprom data problems...

"You don't need to take any precautions on EEPROM access when using CVAVR.
However you must use these techniques:
- proper power supply
- external reset supervisor IC
- when storing important data in EEPROM, store the same value in 3 different variables.
When reading the data, read all 3 variables and compare their values.
If one of the values doesn't match the other two, re-write it with the correct value read from the other two.

This will most likely solve your problems.

"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ahh, the old "majority must be right" proposition! But, in the case of an EEPROM subject to "corruption", it can get you a long ways.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yea, Jim but the part about the reset supervisor may be the key. I use one on my AVR boards and also depend on EEPROM data and very rarely have a problem. I can see where if things are real bad even three variables for the same value will not help.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Simply enabling BOD eliminates many problems?
Would there be a problem for example if you read EEPROM into a variable at startup without BOD, then never again? Or is it mostly when you get flickering power when your code is running and youre constantly reading from eeprom?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

tkurowski wrote:
Simply enabling BOD eliminates many problems?
Would there be a problem for example if you read EEPROM into a variable at startup without BOD, then never again? Or is it mostly when you get flickering power when your code is running and youre constantly reading from eeprom?

My situation is the former, I read the values once at startup and never again, and I've got what should be solid voltage to the boards. But I've never actually looked at the turn-on waveform of this power supply, which I should do next.

Mike

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

tkurowski wrote:
Simply enabling BOD eliminates many problems?
Would there be a problem for example if you read EEPROM into a variable at startup without BOD, then never again? Or is it mostly when you get flickering power when your code is running and youre constantly reading from eeprom?

Problem is, that when there is a brown-out condition, the CPU can do ANYTHING. Bit's in the CPU's register will change at random, so the end result is a random operation, or set of operations. Bottom line, always use a brown-out detector. Either the internal one, or an external one.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I agree, I have had some very curious things happen to processors operating at brownout conditions. In one particular instance, an MSP430 managed to rewrite flash, which is very hard to do (there is a lockout magic-key register you need to write a valid value to in order to run the peripheral).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was very puzzled once when a CPLD on a board I was developing randomly stopped working. I eventually twigged that turning my PC on and off with the programming cable attached to the board was waggling the pins on the parallel port I was using for programming, and corrupting the CPLD memory. That sort of thing is unlikely with the current USB interfaces.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you want to use the EEPROM, you must enable the brownout reset or connect a proper working undervoltage reset circuit. :!:

Furthermore, if a crystal was used, you must always set the maximum reset delay.
A crystal may need up to 50ms to oscillate stable. :!:

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thats awesome. Good to know that I've randomly been doing all the right things :D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My early projects kept suffering from EEPROM corruption on startup, despite following the extensive advice from Atmel. A clean on-off switch and a decent size cap across the supply help too.

Since they added the BOD functions and the timeout on writing EEPROM, things seem to be OK.

I think that some individual ICs are more susceptible than others too!.

Cheers,

Joey

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, I enabled BOD and the problem seems to have gone away. Where before I could kill a unit with just a few power cycles, now I couldn't kill any of 8 units with a few dozen cycles. The power supply turn-on/turn-off wasn't dirty, but it did have an exponential waveform.

So, lesson learned. EEPROM is very fragile. At least in the AVR.

Mike

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

EEPROM is very fragile. At least in the AVR.

No, it isn't.

When supply power is dropping, there is almost always a ramp down. Steep or shallow, it doesn't make much difference. Take a time slice of that ramp say every millisecond. Note that your AVR may be rated to, say, 2V Vcc min.

During each of those slices, the AVR executes many instructions. As you get to the 2V level, everything is still traveling along nicely.

Once you get below the rated min supply voltage, at some point pieces of the AVR are going to give up and not run properly. I cannot tell you which subsystem will fail, and at exactly what supply voltage level.

We can tell you that on e of the common symptoms is that an EEPROM write is triggered. And that is to the EEAR address. If EEAR "dies" to 0 first, then address 0 of EEPROM will be wiped out. If not, it will be whatever address EEAR is pointing to.

Other subsystems may also exhibit "faulty" operation when run below spec. The EEPROM is noticeable because the evidence is left behind. One could probably construct a scenario with different legs of a transistor bridge on different AVR I/O ports and one dies before the other, causing a short in the bridge. Does that mean the AVR's I/O ports are "fragile"?

The BOD is there to prevent the microcontroller from >>attempting<< to run when in an out-of-spec situation. Use it--AFAIK every AVR model has one, and it works fine. So it costs nothing. As mentioned above, we all had external devices for that function on our production designs before the internal BOD became commonplace. (Mega8? CRS)

I've always felt that the byte-writable EEPROM on the AVR is one of the nicer features.

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lee,

I guess there's an argument to say that BOD should be enabled by default as it doesn't make much sense for it not to be used.

Unfortunately there's an even stronger argument that Atmel cannot guess what your planned Vcc is going to be so sadly they cannot make it the default.

Maybe the datasheets should at least start with something like "Warning: for correct operation the AVR should have BOD enabled, once you have determined Vcc pick the right BOD level and enable it" ?

(I suppose there is the power consideration of using BOD too?)

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Quote:

EEPROM is very fragile. At least in the AVR.

No, it isn't.

Well look at it this way. AVR flash doesn't seem to corrupt on power down. AVR EEPROM does, even when there is no code in the program that writes to EEPROM. I'd call that a problem. But as you note, there is a free and easy solution, and I can live with that.

Mike

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I switched the ADC calibration from flash into EEPROM based on this forum which suggested low-voltage reads were OK as long as no writes were attempted! I don't want to enable the BOD as that is a continuous 50ua load on the battery. Well, I know what to look for and if I have problems can always switch back to flash.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I always thought the inherent brown out levels were dumb on the fuses.
One is 4.3V, and the next is 2.7V on my avr.
I tested my particular AVR and found it operated down to 3.1V. I don't like that I need an external BOD for a ~3.5V brown out, cus 4.3 is too high in my application (don't want it to reset too early due to external components drawing a lot of current when starting to move (actuators)), and 2.8 is dangerously too low.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I don't want to enable the BOD as that is a continuous 50ua load on the battery.

That is certainly a consideration. Atmel has addressed this to some extent (large extent?) with the "sleeping BOD". (Is that on all P chips?)

Quote:

I always thought the inherent brown out levels were dumb on the fuses.
One is 4.3V, and the next is 2.7V on my avr.

That is indeed a "trap". The levels are fairly convenient for a 5V and 3.3V app.

==============
But if levels are inconvenient, you should add an external device that fits your needs. Don't enter there unsheathed without proper protection. ;)

[Do you really have dips in the regulated Vcc? Scary.]

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

I was having the same problem, fois resolved with the answers contained above ... I have several positions of the eeprom being always recorded to eeprom in position 0x0000 I lost the data, soon I stopped using the position 0x0000, I also decided to activate BOB, it was already active.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's an 8 YO thread, but the EEPROM being erased randomly at 0x0000 is old known fact and most people don't use it particularly with older chips.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
It's an 8 YO thread, but the EEPROM being erased randomly at 0x0000 is old known fact ...

 

"known fact", and tribal knowledge, and similar?  I'll agree.

 

Randomly?!?  Not so much.  There is nothing random about it.  Without an appropriate BOD enabled (and I'd really like to explore the claim in #26 that it in fact was/is enabled at an appropriate value), and the supplyV drops below a safe level, and with no BOD the AVR keeps trying like a steer, and one of the things that happens is that the EEAR register(s) cannot hold their value, and then an EEPROM erase/write operation is carried out at address 0 instead.

 

 

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

All OT, so ignore at will:

williambarbosalima wrote:
I also decided to activate BOB

1. StarTrek in the AVR quadrant: "Please state the nature of your EEPROM emergency.." (cf. https://www.youtube.com/watch?v=... )

2. Been a while since we've seen him, hasn't it..

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Sat. May 13, 2017 - 03:41 PM