Internal EEPROM problems Has anyone else had any?

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

Hi All

Can the internal EEPROM ever get corrupted and over write locations which were not meant to be over written.

I ask this because I am running the Bitcloud stack with some modification, such as a when a button is pressed it save the EXPANID to eeprom. Then the AVR would reset itself and it would automatically always join a particular network only.

But on a certain occasion I found that my AVR did not boot up correctly when a button was pressed, the stack does use the EEPROM . I am thinking it could be related to VCC? Can this be a possibility.

Now if VCC is lost and re applied very quicly, could that mess up some counter while writing to EEPROM is still intact. This would mean what i am writing or part of what i am writing is written to a wrong long location.

My VCC connection is bit lose and maybe in the particular case when pressing the button it done something internally

This was a odd behaviour and was wondering if anyone else has had EEPROM corruption before.

I have come to the conclusion it's a EEPROM problem because by enabling the EEPROM save in the FUSE, and then flashing the AVR made no change , but disabling EEPROM save and the RE flashing the AVR got it back to normal once again.

Maybe I could try to replicate the problem and then upload a working EEPROM file and reboot.

But i would like to know has anyone else had EEPROM issues

Regards

DJ

Thanks

Regards

DJ

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

Quote:

But i would like to know has anyone else had EEPROM issues


Shortest answer: make sure that the brown-out detector is enabled.

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 think it is, but only to 1.8V

Thanks

Regards

DJ

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

Okay, the long answer: The EEPROM is sensitive to low voltage. Read the datasheet for your particular AVR (which you never told us) operating at whatever VCC you are running (which you never told us).

What Lee was trying to tell you is that running the AVR at too low a voltage can cause problems in the EEPROM, including writing to areas that are not supposed to be written, writing the wrong values, and so on. The brown-out detector prevents the AVR from running if the voltage drops below the set value.

The down side to using the brown-out detector is that the AVR immediately goes into reset when the voltage gets below that level. No warnings, no interrupts. In the best case, you have an external supply that can warn the AVR that power is about to go out. If that signal is on an interrupt, your AVR can then prepare itself for the brown-out.

Regardless, if you use the brown-out detector, you should put a check early in your wake-up sequence that checks the status bits in MCUSR to see if you are coming out of a brown-out. You may need some special processing to properly restore your state in this case (or may be not :wink:).

Hope this helps!

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

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

Quote:

I think it is

Not a good answer.

To Stu: re checking for a brown-out reset. Think about it: the same considerations apply to a power-on reset detected--the voltage still dropped below the BOD level, the same conditions apply, except it kept droppping.

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

Hey Thanks

Well my brown out is set to 1.8V.
I am using ATMEGA 1284P and using it with 3.3V.

I will check my datasheet on what is the lowest voltage for EEPROM is. I guess moving a rounf a loose connection could make it look like a drop in voltage due to the CAPS.

DJ

Thanks

Regards

DJ

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

Quote:

Well my brown out is set to 1.8V.
I am using ATMEGA 1284P and using it with 3.3V.

Eh? 2.7V is the usual BOD level for 3.3V supply. I don't have a 1284P datasheet to check but presumably there is a BOD level around 2.5..3.0 volts?

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

Ah Ok,1.8V is what was recommend by Atmel for there stack. But I will set it to 2.7V. The datasheet does show it can operate at 1.8V.

I been trying to replicate the EEPROM corruption, but have been unsucessful. So I guess I will just set it to 2.7.

I guess internall registry for 1.8V and 2.7V would be the same, so this would imply i will not need to change any code. But anyway, the stack has it compiled libary so I can not do much to it.

Regards

DJ

Thanks

Regards

DJ

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

Hi,

You might take a look at my eeprom structure library posted here at avrfreaks:

https://www.avrfreaks.net/index.p...

Honestly, of the 4 libraries I posted, I thought this one would be the most popular although it hasn't been.

This will automatically do a round robin wear leveling on the entire eeprom area with the data you want to store, store it twice automatically, use a crc16 value to ensure integrity, and automatically load/recover from the newest written stable structure without any work on your part. I recall an Atmel wear leveling document that had a similar concept as this although it didn't have code or crc16 protection if I recall.

If you are in the middle of writing to eeprom and it isn't fully written properly before power loss, then the previous structure that has integrity will automatically be recovered. No more corruption issues.

Good luck,

Alan

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

If things are written twice, then would this mean i will have half the memory.

What about when the EEPROM is being used by the stack, which i have no access to.

DJ

Thanks

Regards

DJ

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

Hi DJ,

djoshi wrote:
If things are written twice, then would this mean i will have half the memory.

Yes, and hopefully you would be using less than that. The smaller the data you have to store, the more times you can store it. The more times you can store it means you have more copies to recover from. It also means your eeprom memory will last longer and not hit its write design limit as quickly.

One technique that can be used is to pack the data more tightly in a structure and then save that packed structure to eeprom. For example, I use an unsigned char X for a variable in C, but I pack it into a single bit in eeprom. You may find that what you are storing in eeprom could be packed quite a bit.

Here is an example of 5 variables being stored in a single eeprom byte. 4 flags and a 4 bit variable:

    memset(&Settings,0,sizeof(Settings));
    b=LoadEEPROMStructure(0,s1);
    if (b)
      {
        Settings.ReminderPressMaintenance=                                  (s1[1]&_BV(7))>>7;
        Settings.ReminderPressMaintenanceType=                              (s1[1]&_BV(6))>>6;
        Settings.StartupAskSpecifyPowderMeasure=                            (s1[1]&_BV(5))>>5;
        Settings.StartupDisplayPressTotals=                                 (s1[1]&_BV(4))>>4;
        Settings.ReminderLowPower=                                          (s1[1]&(_BV(3)|_BV(2)|_BV(1)|_BV(0)))>>0;
        memcpy(&LastSettings,&Settings,sizeof(LastSettings));
      }
    else
      {
        Settings.ReminderPressMaintenance=                                  ENABLED;
        Settings.ReminderPressMaintenanceType=                              PMM_BY_ROUNDS;
//zc    Settings.StartupAskSpecifyPowderMeasure=                            DISABLED;
        Settings.StartupDisplayPressTotals=                                 ENABLED;
        memset(&LastSettings,0,sizeof(LastSettings));
      }

Since my source code is available, you could always go through it and recode it to remove the stored twice feature if you need the space. It might be easier for you to just see how the crc16 stuff works in my code and duplicate that for your project if you only want to store things one time (or have room to only store one time).

djoshi wrote:
What about when the EEPROM is being used by the stack, which i have no access to.

I'm not sure I am following your question. The only overhead in my code that is in eeprom is 4 bytes per structure. 2 bytes for the versioning and 2 bytes for the crc16. You can always read the eeprom area manually and not use the library code to do it.

Good luck,

Alan

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

I found that when using the tiny44 with a lithium cell that a BOD of 2.3V was the absolute minimum i needed to avoid memory corruption when writing to EEPROM, any lower and the voltage just drops too quickly and the MCU does not have enough time to complete the EEPROM write before undervoltage causes corruption (Lithium cell voltage falls off a cliff below 2.7V). So if possible use 2.7V for safety, and make sure your clock rate is acceptable down to 1.8V operation (see "Speed grades" section of the datasheet there is a graph of clock speed vs Vcc).

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

Well this subject has come back to life for me. My board has an external reset part (TI TPS3828-50) that trips above 4 volts with 5 vcc. BOD was not enabled over some years of use. The only functions that write to the eeprom require an exact char from terminal while an exact i/o line is pulled low. Then key presses step into the code and write the values to eeprom. Occasionally we have seen boards with the value cleared to zero. Zero would not be the value we store during programming.

My plan is to enable BOD and also do a triple storage of the values and a check that two of 3 match when they are read. If we can not find two that match we will call an error. I just wonder if we are seeing a reliability problem with the eeprom. My device is always an atmega128L-8 part. :?:

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

I found it helpful when tracking EEPROM "trashing" situations to park EEAR to a known guard value. I did a dummy read of a guard location containing 0x55 (or whatever) at the end of each main loop.

Then when you examine the EEPROM contents of the devices under test you can see if the guard location has been disturbed.

[The last time the root cause was BOD not enabled. "Not my fault"--directly. There was a fault in the keyfob programmer used at the field test sites that did not set the BOD properly. Fix that problem--and EEPROM "corruption" goes away. It seems to me from my experience with this over the years that with no BOD the AVR (several models and generations) goes "rogue" when supply V gets too low and very weird things happen. I'd verify that your external BOD is really tripping.]

There are approaches to do things "right". It is easier when you don't have EEPROM filled with valuable stuff. You can have your parameter "block" in one area and have it checksummed. You can have a backup block (checksummed) in another area. And maybe even a thrid with "factory default" "limp home" values.]

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

Thanks Lee. I will enable the BOD today and set for the higher level. I do have a marker pattern in there of 55h repeated for 4 bytes as I recall. I have to presume that somehow the external reset is not keeping us out of trouble so adding the BOD should help. It would be interesting to know if someone ever set up a test on a board and cycled the power over days with firmware looking for corrupt eeprom data with BOD enabled. I used to have a timer motor with some microswitches and a cam setup to cycle AC on and off to test a product.

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

Quote:

It would be interesting to know if someone ever set up a test on a board and cycled the power over days with firmware looking for corrupt eeprom data with BOD enabled.

Yes, yes, yes. We've done several fairly exhaustive tests over the years. The short answer is that the AVR internal BOD works quite well, and when set you won't get EEPROM corruption from a rogue AVR.

And (me being the firmware programmer) I can't fix in software noise problems that are severe enough to damage components. AVRs are pretty tough IME, but if you hit them hard enough with noise spikes they will go rogue and anything can happen. (Noise spikes can "trick" the BOD into not tripping.)

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

theusch wrote:
Quote:

And (me being the firmware programmer) I can't fix in software noise problems that are severe enough to damage components. AVRs are pretty tough IME, but if you hit them hard enough with noise spikes they will go rogue and anything can happen. (Noise spikes can "trick" the BOD into not tripping.)

Yes, I have seen short high energy noise spikes that caused an attiny85 to 'crash' even with BOD enabled at 1.8V with 2.5V supply. The 'fix' was a re-layout of the PCB to isolate the ground/power of the '85 (and its bypass cap) from the main switching supply ground plane.

cheers,
george.

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

Hi alwelch,

How much eeprom space to you have? How much data do you have to store? I wrote my EEPROM library exactly for this reason - to make sure that what you retrieve IS valid data and also for wear leveling...

Thanks,

Alan

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

alwelch wrote:
It would be interesting to know if someone ever set up a test on a board and cycled the power over days with firmware looking for corrupt eeprom data with BOD enabled.
I think someone published the results of such a test some month ago. I can't find it with the forum search, but you can try. AFAIR without BOD it was almost predictable EEPROM corruption, with the BOD no corruption occurred in that test.

Stealing Proteus doesn't make you an engineer.

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

My unscientific test a few years ago now, was to connect -ve power from the power supply to my (at that time) tiny15 design. The positive went from the power supply to a screw driver. The +ve power to the tiny15 was a croc (alligator) clip lead from one end of a bastard file. I would then run the screw driver up and down the file - LOTs and LOTs of power on/off cycles in very short order. Without BOD the eeprom would corrupt almost immediately, with BOD it was rock solid and I got bored of filing down my screw driver :)

But, as I wrote above, there are some situations with VERY short noise pulses that can get past the BOD and cause the AVR to crash - i.e. not a clean reset...

cheers,
george.

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

Interesting replies and thanks for those insights! I looked at my external reset data sheet and noted that it does not assert reset until vcc is 1.2 volts or higher. It has an open drain switch on it and I have a 10k external resistor to VCC tied to the reset line. I certainly will enable BOD and the level fuse. I wonder about tacking a small cap on that reset node to ground. The right value might ensure the reset does not rise while the external reset chip is looking for that 1.2 vcc min. level. I have lots of bypass caps on the board including ones at the AVR. I have never had a bad AVR but I have seen the rare unit with the eeprom loss. Sounds good that with BOD on it will reduce those problems.