Can Reading EEPROM Data Cause That Particular Data Corrupt?

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

Hi all freaks out there,

I can find a lot of information about EEPROM corrupt during EEPROM write process - supply voltage not stable while writing, interrupt happen while writing.

However, while reading a EEPROM from a location, can that particular EEPROM data corrupted?

Thanks in advance.

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

No.

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

Hi David,

Cuurently i have one project, the value at EEPROM location 0x31 is programmmed along with flash. No write operation is perform when software is running, only read at that location.

But problem occured, somehow the value at that location changed, no write operation, only read.

Is it possible while reading the EEPROM, interrupt happen and cause the corruption?

Thanks
Chyun3

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

EEPROM corruption is often traced to BOD not being used. So I guess the question is whether you have BOD enabled?

Cliff

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

I can see no reason for location # 0x31 to alter. You have to follow a careful sequence to write to the eeprom.

So unless you are part way through an intentional write operation and the power fails, I cannot see any problem.

What value does this location change from / to ?

Enabling brown-out detection is probably always worthwhile. Do you have a very bad power supply or a very noisy electrical environment?

Or perhaps the .EEP file did not get programmed with the flash.

David.

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

clawson wrote:
EEPROM corruption is often traced to BOD not being used. So I guess the question is whether you have BOD enabled?

Cliff

Hi Cliff,

For my application, the BOD is disabled, but my application only read that EEPROM location, not write. Will this corrupt that EEPROM data?

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

The problem with the BOD/EEPROM is not during "normal use" but as the power rails to the AVR either rise at power on or sag at power off. As the AVR is not being held in reset until the power is at a suitable level the AVR core may be underpowered at which point it does "weird things". Apparently one of those weird things that can happen is the corruption of the EEPROM (though usually location 0x00)

Cliff

Last Edited: Thu. Aug 13, 2009 - 10:04 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would be very sceptical of location 0x31 being corrupted.

The simple solution is to use the brown-out-detection fuse.

Bt for peace of my mind, why not write a little test program that writes a fixed pattern to each eeprom location.

Then switch your AVR on and off until you can read a "changed" value. If you are encountering problems it is likely to be either a very slow rise and fall of Vcc, or some noise on Vcc. Using 0.1uF ceramic capacitors close to your Vcc pin should help to remove electrical noise.

There is probably some advice in an app note about a small capacitor on RESET. If the RESET pin only goes high after the AVR proper has adequate Vcc.

The BOD fuse seems an awful lot simpler.

David.

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

Quote:

I would be very sceptical of location 0x31 being corrupted.

The simple solution is to use the brown-out-detection fuse.


Totally agree on #2--you >>need<< a BOD on an AVR that does >>any<< EEPROM operations. Trust me. Been there, done that.

On #1: With the described app the read-only location >>can<< get corrupted. Been there and done that too; with the T-shirt to prove it. Chances are that the EEARx registers are sitting at that location during most of the time, left there after the last operation. With no BOD when the supply V dips into no-man's-land EEARx is likely sitting at that location and when the AVR gets starved and goes nutz, that will be the location corrupted.

So for OP's question: it isn't the reading of EEPROM that corrupts the location, it is the AVR going awry at supply voltages lower than spec. A BOD solves it.

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

If BOD was not enabled, the EEPROM byte, which was pointed by EEAR may be corrupted.

If power consumption of the BOD was an issue, you should use an external undervoltage reset circuit.

Peter

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

Agree, i will write code to continuously read the EEPROM location, and in the same time disturb the 5V supply, woth BOD disable.

Will inform the result once done...

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

Hi guys,

I have writen a software that continuously read all the EEPROM from location 0x00 to 0xFF,

with all these location memory assigned with 0xAA value,

then i start to change the supply voltage step by step from 3V, 2.9V ,2.8V....until 1.0V. I let the MCU run for around 5-10 minutes before i step down voltage.

Guess what is the result...

All the memory location from 0x00 o 0xFF still maintain the value 0xAA. This experiment prove that reading the EEPROM while the voltage is not stable will not cause EEPROM data to corrupt.

Thanks
Chyun3

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

Addition note to the above post, the Brown-Out detection is also Disabled.

Thanks
Chyun3

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

No, your experiment doesn’t proof anything. You tested EEPROM in relatively stable conditions; try to do the same when processor is powered by noisy power supply – 2-5V during reading EEPROM and run tests for longer.

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

it may also require a short brown-out condition, that returns to a valid power level to create the error.

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

TFrancuz wrote:
No, your experiment doesn’t proof anything. You tested EEPROM in relatively stable conditions; try to do the same when processor is powered by noisy power supply – 2-5V during reading EEPROM and run tests for longer.

Hi,

I also tested this conditon, turning the power supply voltage from 1V to 5V and again turn down the voltage from 5V to 1V.I keep doing this for around 15 minutes and read back the EEPROM, all the value from location 0x00 to 0xFF still 0xAA, no corruption happened.

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

glitch wrote:
it may also require a short brown-out condition, that returns to a valid power level to create the error.

For this tesing, BOD is disabled, to have better simulate of whether low VCC can cause EEPROM to corrupt while continously reading EEPROM.

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

I can argue with your results. I had about 10 ATMega8 processors connected over relatively long bus – about 100m. All were powered through the bus. Within about month or so I noticed in some processors errors in EEPROM – of course none of them have written anything to EEPROM during this time. All processors by my mistake had switched off BOD fuse. After this bad experience I turn on BOD and problems disappear.

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

TFrancuz wrote:
I can argue with your results. I had about 10 ATMega8 processors connected over relatively long bus – about 100m. All were powered through the bus. Within about month or so I noticed in some processors errors in EEPROM – of course none of them have written anything to EEPROM during this time. All processors by my mistake had switched off BOD fuse. After this bad experience I turn on BOD and problems disappear.

Your application donot write EEPROM, but do your application read from EEPROM with BOD disable?

Or maybe i need to test it for longer time to get the effect...

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

Well behaved power supplies with well behaved programs will probably never cause any problems.

In the real world you have noisy power supplies and sometimes even errant programs.

Now a simple solution is to use the built-in BOD facility. This would always seem wise for products that may encounter hostile conditions.

Of course it may be that you have a large number of units already in the field without the BODEN fuse set. Only you can know or guess what your users will do with your product.

If the application is non-critical and runs on a good office power supply, just sleep soundly with your fingers crossed.

If you have already had a problem then you either re-program the BODEN in the field or glue your fingers together before taking sleeping pills.

David.

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

chyun3 wrote:
Hi guys,

I have writen a software that continuously read all the EEPROM from location 0x00 to 0xFF,
with all these location memory assigned with 0xAA value..All the memory location from 0x00 o 0xFF still maintain the value 0xAA.


When doing this test how do you know you are reading the correct 0xAA?

One possible failure scenario is that the address gets corrupted by some power supply glitch, rather than the data. That is data gets read from the wrong location. It would be better if each byte contained different data. I recognize that this is somewhat different than the permanent memory corrupt you are looking for.

To write proper memory test you really need to know how the bits are laid out in the X/Y pattern of the memory being tested. Bit-0 of a byte may not necessarily be physically next to Bit-1 of the same byte.

This can cause simplistic patterns like 0x55/0xAA tests to pass a memory that is bad, because they can hide Inversion Coupled Faults.

IEC60730 gives some recommendations for memory tests. Still not perfect because it too does not address the physical bit layout. See "March B" at the end of http://www.atmel.com/dyn/resources/prod_documents/doc7715.pdf.

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

chyun3 wrote:
glitch wrote:
it may also require a short brown-out condition, that returns to a valid power level to create the error.

For this tesing, BOD is disabled, to have better simulate of whether low VCC can cause EEPROM to corrupt while continously reading EEPROM.

I wasn't talking about enabling the BOD fuse. I understand you are testing with your fly unzipped (AKA the BOD is disabled)

I was saying that a short brown-out event (AKA VCC too low)[timescale: ~1CPU cycle] may be what is required to cause the failure. When this happens the processor misbehaves for a brief moment, and then continues on normally, as VCC is valid again. But that single event could change a read of EEPROM into a write. If the brown-out detector was enabled, this would not be possible, as it would immediately put the processor into reset on the brown-out event.

The theory, and practice behind this is sound. The guys that hack satellite TV cards glitch the voltage to the cards in this way, as well as glitch the clock, in order to cause the card to misbehave in a very predictable manner.

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