EEPROM checksum error

[Dummy]

What is the possible cause of EEPROM checksum error?
Could magnetic field corrupt the EEPROM data? Any design guidelines to
prevent this potential failure?

 

[Luhan Monat]

Dummy wrote:

What is the possible cause of EEPROM checksum error?
Could magnetic field corrupt the EEPROM data? Any design guidelines to
prevent this potential failure?

Eeproms, as far as I know, do not have this feature. Something else
(the programming device) must be making one up and storing it in the
eeprom - somewhere.

You will need to provide more specific information.

--
Luhan Monat (luhanis 'at' yahoo 'dot' com)
"The future is not what it used to be..."
http://members.cox.net/berniekm

 

[Ken Taylor]

"Dummy" <ahkit1021@yahoo.com> wrote in message
news:74bb84c0.0503011834.4ce69faf@posting.google.com...

What is the possible cause of EEPROM checksum error?
Could magnetic field corrupt the EEPROM data? Any design guidelines to
prevent this potential failure?

When did this occur? After a long time in circuit? After programming?

Ken

 

[Dummy]

"Ken Taylor" <ken@home.nz> wrote in message news:<1bbVd.5787$1S4.626359@news.xtra.co.nz>...

"Dummy" <ahkit1021@yahoo.com> wrote in message
news:74bb84c0.0503011834.4ce69faf@posting.google.com...
What is the possible cause of EEPROM checksum error?
Could magnetic field corrupt the EEPROM data? Any design guidelines to
prevent this potential failure?

When did this occur? After a long time in circuit? After programming?

Ken

The range of usage spanned from 6 months to 2 years. EEPROM is used in
mobile radios. All radios are equipped in car or truck. Suspected to
be noise at the supply line that caused the EEPPROM checksum error,
but experiment showed that the noise injected at supply line is
filtered by regulator circuit. Power supply line to EEPROM is
confirmed to be clean regardless the amount of noise exist at main
supply. What could have caused the checksum error?

 

[Robert Monsen]

Dummy wrote:

"Ken Taylor" <ken@home.nz> wrote in message news:<1bbVd.5787$1S4.626359@news.xtra.co.nz>...

"Dummy" <ahkit1021@yahoo.com> wrote in message
news:74bb84c0.0503011834.4ce69faf@posting.google.com...

What is the possible cause of EEPROM checksum error?
Could magnetic field corrupt the EEPROM data? Any design guidelines to
prevent this potential failure?

When did this occur? After a long time in circuit? After programming?

Ken


The range of usage spanned from 6 months to 2 years. EEPROM is used in
mobile radios. All radios are equipped in car or truck. Suspected to
be noise at the supply line that caused the EEPPROM checksum error,
but experiment showed that the noise injected at supply line is
filtered by regulator circuit. Power supply line to EEPROM is
confirmed to be clean regardless the amount of noise exist at main
supply. What could have caused the checksum error?

Make sure you follow all the recommendations of the manufacturer of the
eeprom.

Is the eeprom programmed in the field, or is it just programmed once at
the factory and then used from then on? Is it possible there is a
software error causing this? EEPROMs usually use keyed programming
sequences to prevent inadvertent corruption.

Make sure you lock out interrupts while programming the thing.

--
Regards,
Robert Monsen

"Your Highness, I have no need of this hypothesis."
- Pierre Laplace (1749-1827), to Napoleon,
on why his works on celestial mechanics make no mention of God.

 

[Ken Taylor]

"Robert Monsen" <rcsurname@comcast.net> wrote in message
news:i-qdnTpRspPbI7vfRVn-og@comcast.com...

Dummy wrote:
"Ken Taylor" <ken@home.nz> wrote in message
news:<1bbVd.5787$1S4.626359@news.xtra.co.nz>...

"Dummy" <ahkit1021@yahoo.com> wrote in message
news:74bb84c0.0503011834.4ce69faf@posting.google.com...

What is the possible cause of EEPROM checksum error?
Could magnetic field corrupt the EEPROM data? Any design guidelines to
prevent this potential failure?

When did this occur? After a long time in circuit? After programming?

Ken


The range of usage spanned from 6 months to 2 years. EEPROM is used in
mobile radios. All radios are equipped in car or truck. Suspected to
be noise at the supply line that caused the EEPPROM checksum error,
but experiment showed that the noise injected at supply line is
filtered by regulator circuit. Power supply line to EEPROM is
confirmed to be clean regardless the amount of noise exist at main
supply. What could have caused the checksum error?

Make sure you follow all the recommendations of the manufacturer of the
eeprom.

Is the eeprom programmed in the field, or is it just programmed once at
the factory and then used from then on? Is it possible there is a software
error causing this? EEPROMs usually use keyed programming sequences to
prevent inadvertent corruption.

Make sure you lock out interrupts while programming the thing.

--
Regards,
Robert Monsen

All that good stuff....

Also, are these two-way radios? Do the EEPROM's get altered during normal
use, in which case is it possible RF is causing problems?

Ken

 

[Pooh Bear]

Dummy wrote:

What is the possible cause of EEPROM checksum error?
Could magnetic field corrupt the EEPROM data? Any design guidelines to
prevent this potential failure?

*What* checksum ? How do you calculate 'your' checksum ?

What type of Eeprom ? 24Cxx family for example ?

Far too little info supplied to meaningfully respond.


Graham

 

[Harold Ryan]

Checksum is just the addition of each byte of data. At the end of the file,
another byte or word is added that will total all of the bytes to zero. If
any of the bytes are corrupt, the total sum of all the bytes will not be
zero. A loose wire or strong magnetic field may cause this problem.
Harold





"Pooh Bear" <rabbitsfriendsandrelations@hotmail.com> wrote in message
news:422913CA.21AE9381@hotmail.com...

Dummy wrote:

What is the possible cause of EEPROM checksum error?
Could magnetic field corrupt the EEPROM data? Any design guidelines to
prevent this potential failure?

*What* checksum ? How do you calculate 'your' checksum ?.

What type of Eeprom ? 24Cxx family for example ?

Far too little info supplied to meaningfully respond.


Graham

 

[Spehro Pefhany]

On 2 Mar 2005 21:05:59 -0800, the renowned ahkit1021@yahoo.com (Dummy)
wrote:

"Ken Taylor" <ken@home.nz> wrote in message news:<1bbVd.5787$1S4.626359@news.xtra.co.nz>...
"Dummy" <ahkit1021@yahoo.com> wrote in message
news:74bb84c0.0503011834.4ce69faf@posting.google.com...
What is the possible cause of EEPROM checksum error?
Could magnetic field corrupt the EEPROM data? Any design guidelines to
prevent this potential failure?

When did this occur? After a long time in circuit? After programming?

Ken

The range of usage spanned from 6 months to 2 years. EEPROM is used in
mobile radios. All radios are equipped in car or truck. Suspected to
be noise at the supply line that caused the EEPPROM checksum error,
but experiment showed that the noise injected at supply line is
filtered by regulator circuit. Power supply line to EEPROM is
confirmed to be clean regardless the amount of noise exist at main
supply. What could have caused the checksum error?

What kind of EEPROM? Data corruption in EEPROMs is not uncommon-
caused directly by electrical noise, or by faulty design of the
controlling microprocessor system, either wrt to EMI or power supply
supervision. Redesign to decrease EMI susceptibility and PS issues,
and then (and ONLY then) tweaks to add redundancy to the non-volatile
storage can reduce the issue to insignificance even for large
quantities of units in challenging applications.


Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com

 

[Pooh Bear]

Harold Ryan wrote:

Checksum is just the addition of each byte of data. At the end of the file,
another byte or word is added that will total all of the bytes to zero. If
any of the bytes are corrupt, the total sum of all the bytes will not be
zero. A loose wire or strong magnetic field may cause this problem.
Harold

I'm broadly familiar with this thanks. I'm less familiar with why Eprom
programmers of old seemed to produce different checksums according to
manufacturer.

The OP still hasn't explained *what checksum* he's talking about under what
conditions.

Can he even validate the file ?


Graham

 

[Pooh Bear]

Robert Monsen wrote:

Dummy wrote:
"Ken Taylor" <ken@home.nz> wrote in message news:<1bbVd.5787$1S4.626359@news.xtra.co.nz>...

"Dummy" <ahkit1021@yahoo.com> wrote in message
news:74bb84c0.0503011834.4ce69faf@posting.google.com...

What is the possible cause of EEPROM checksum error?
Could magnetic field corrupt the EEPROM data? Any design guidelines to
prevent this potential failure?

When did this occur? After a long time in circuit? After programming?

Ken


The range of usage spanned from 6 months to 2 years. EEPROM is used in
mobile radios. All radios are equipped in car or truck. Suspected to
be noise at the supply line that caused the EEPPROM checksum error,
but experiment showed that the noise injected at supply line is
filtered by regulator circuit. Power supply line to EEPROM is
confirmed to be clean regardless the amount of noise exist at main
supply. What could have caused the checksum error?

Make sure you follow all the recommendations of the manufacturer of the
eeprom.

Is the eeprom programmed in the field, or is it just programmed once at
the factory and then used from then on? Is it possible there is a
software error causing this? EEPROMs usually use keyed programming
sequences to prevent inadvertent corruption.

Make sure you lock out interrupts while programming the thing.

The serial interface is timing tolerant IME. Never seen false data as a result of background
interrupts.


Graham

 

[Dummy]

Pooh Bear <rabbitsfriendsandrelations@hotmail.com> wrote in message news:<422BE817.F051E6A@hotmail.com>...

Harold Ryan wrote:

Checksum is just the addition of each byte of data. At the end of the file,
another byte or word is added that will total all of the bytes to zero. If
any of the bytes are corrupt, the total sum of all the bytes will not be
zero. A loose wire or strong magnetic field may cause this problem.
Harold

I'm broadly familiar with this thanks. I'm less familiar with why Eprom
programmers of old seemed to produce different checksums according to
manufacturer.

The OP still hasn't explained *what checksum* he's talking about under what
conditions.

Can he even validate the file ?


Graham

The EEPROM will be programmed in factory before shipping out to
customer.
Everytime when radio is turned on, checksum will be verified. Checksum
error will occur when any bytes are corrupted in the EEPROM. If data
corrupted during radio ON, any checksum error won't be detected until
the next radio turned OFF and ON cycle.

The corrupted bytes are at random EEPROM address.
Some of the parts could be recovered after re-programming while some
could not. For those parts which damaged permanently, failure analysis
showed cell overwritten. Trying to inject some noises to EEPROM data
or supply line while performing write operation could cause checksum
error. But all the voltages supplied to EEPROM are clean when in
normal use. The filter and regulator have taken care of the noises. So
it's not right to point to the noise as the culprit.

Most of the radios failed after being in the field from 6 months to 2
years.

 

[Robert Monsen]

Dummy wrote:

Pooh Bear <rabbitsfriendsandrelations@hotmail.com> wrote in message news:<422BE817.F051E6A@hotmail.com>...

Harold Ryan wrote:


Checksum is just the addition of each byte of data. At the end of the file,
another byte or word is added that will total all of the bytes to zero. If
any of the bytes are corrupt, the total sum of all the bytes will not be
zero. A loose wire or strong magnetic field may cause this problem.
Harold

I'm broadly familiar with this thanks. I'm less familiar with why Eprom
programmers of old seemed to produce different checksums according to
manufacturer.

The OP still hasn't explained *what checksum* he's talking about under what
conditions.

Can he even validate the file ?


Graham



The EEPROM will be programmed in factory before shipping out to
customer.
Everytime when radio is turned on, checksum will be verified. Checksum
error will occur when any bytes are corrupted in the EEPROM. If data
corrupted during radio ON, any checksum error won't be detected until
the next radio turned OFF and ON cycle.

The corrupted bytes are at random EEPROM address.
Some of the parts could be recovered after re-programming while some
could not. For those parts which damaged permanently, failure analysis
showed cell overwritten. Trying to inject some noises to EEPROM data
or supply line while performing write operation could cause checksum
error.

You say they are preprogrammed, but this implies that you are writing
them during normal operation. Which is it?

But all the voltages supplied to EEPROM are clean when in
normal use.

^ Famous last words.

The filter and regulator have taken care of the noises. So

it's not right to point to the noise as the culprit.

Most of the radios failed after being in the field from 6 months to 2
years.

If the eeproms aren't being reprogrammed in the field during normal use,
then a software error is unlikely, unless the magic write sequence is
stumbled upon during a freak crash. If they *are* being reprogrammed
(ie, you are saving some value when the user retunes the radio) then
I'll again say software. I'm telling you, lock out those interrupts!

The other possibility is a bad batch of eeproms. This is fairly
unlikely, but not without precedent*. Attempt to correlate the bad ones
with some lot. Talk to the manufacturer, and ensure that they don't have
a 'known' problem. Also, I wouldn't reuse the corrupted ones just
because you managed to program them. I'd swap them out as soon as practical.

* A company I used to work for decided to save 10 cents a ram chip and
forgo individual testing of the chips by the manufacturer. Sadly, it
turned out that those chips were bad 5 to 10 percent of the time. They
were selling high availability purple ethernet switches for hundreds of
thousands of dollars each. The engineer responsible was of course
promoted to VP, and given vast new responsibilites.

--
Regards,
Robert Monsen

"Your Highness, I have no need of this hypothesis."
- Pierre Laplace (1749-1827), to Napoleon,
on why his works on celestial mechanics make no mention of God.

 

[Spehro Pefhany]

On 7 Mar 2005 22:25:27 -0800, the renowned ahkit1021@yahoo.com (Dummy)
wrote:

The EEPROM will be programmed in factory before shipping out to
customer.
Everytime when radio is turned on, checksum will be verified. Checksum
error will occur when any bytes are corrupted in the EEPROM. If data
corrupted during radio ON, any checksum error won't be detected until
the next radio turned OFF and ON cycle.

The corrupted bytes are at random EEPROM address.

Okay. As I suspected.

Some of the parts could be recovered after re-programming while some
could not. For those parts which damaged permanently, failure analysis
showed cell overwritten. Trying to inject some noises to EEPROM data
or supply line while performing write operation could cause checksum
error. But all the voltages supplied to EEPROM are clean when in
normal use.

Well, what about "abnormal" use, say something that might happen only
rarely? Are you claiming that the supply voltage on these parts was
maintained at 5.0V +/- 5% constantly, never straying lower or higher,
from factory to failure? And noise injected from the supply or other
pins could cause the micro's PC to point to random bits of code.

The filter and regulator have taken care of the noises. So
it's not right to point to the noise as the culprit.

I sure don't think you can conclude that.

Most of the radios failed after being in the field from 6 months to 2
years.

My original comments definitely apply to this situation. Can you post
a link to the schematic of the power supply, micro and EEPROM?


Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com

 

[Charles Edmondson]

Dummy wrote:

Pooh Bear <rabbitsfriendsandrelations@hotmail.com> wrote in message news:<422BE817.F051E6A@hotmail.com>...




The EEPROM will be programmed in factory before shipping out to
customer.
Everytime when radio is turned on, checksum will be verified. Checksum
error will occur when any bytes are corrupted in the EEPROM. If data
corrupted during radio ON, any checksum error won't be detected until
the next radio turned OFF and ON cycle.

The corrupted bytes are at random EEPROM address.
Some of the parts could be recovered after re-programming while some
could not. For those parts which damaged permanently, failure analysis
showed cell overwritten. Trying to inject some noises to EEPROM data
or supply line while performing write operation could cause checksum
error. But all the voltages supplied to EEPROM are clean when in
normal use. The filter and regulator have taken care of the noises. So
it's not right to point to the noise as the culprit.

Most of the radios failed after being in the field from 6 months to 2
years.

Take a GOOD look at power up and power down sequences. A few years ago,
a vendor of mine was having problems with a similiar situation, where an
EEPROM kept getting programmed to random bits here and there. Seemed
that on start up (this was on a parallel port) there were voltage
glitches that JUST HAPPENED to mimic the programming sequence on the
device, which was not supposed to be field programmable! Since this was
a security dongle, and the bits were sometimes the security ID codes,
this was considered a very bad thing!

So, take a look at what occurs during start up and shut downs, and see
if there are any glitches then that can cause you problems!

--
Charlie
--
Edmondson Engineering
Unique Solutions to Unusual Problems

 

[Charles Edmondson]

Robert Monsen wrote:

Charles Edmondson wrote:


Take a GOOD look at power up and power down sequences. A few years
ago, a vendor of mine was having problems with a similiar situation,
where an EEPROM kept getting programmed to random bits here and
there. Seemed that on start up (this was on a parallel port) there
were voltage glitches that JUST HAPPENED to mimic the programming
sequence on the device, which was not supposed to be field
programmable! Since this was a security dongle, and the bits were
sometimes the security ID codes, this was considered a very bad thing!


Were they actually able to observe this, or was it assumed? Dealing with
hardware/software interfaces, it is quite common for programmers to
blame software bugs on hardware 'glitches'. I've seen this again and
again. It is usually a bug that just seems to come and go, possibly due
to some unrelated change in the software that changes the timing or
place in memory where a random pointer is hitting. I have made a living
out of consulting on these kinds of issues.

So, take a look at what occurs during start up and shut downs, and see
if there are any glitches then that can cause you problems!


Yet another goblin to beware of. Thanks.

From their rep, it had definitely been observed. Device had worked for

years, then they came out with a new package. New package also came at
same time they went to a new fab, which had different processes. New
processes made the programming sequence MUCH MORE sensitive, so that
random glitches now created random bits programmed in their devices.
They needed to replace a whole lot of devices in the field, and got a
lot of bad will because of the random failues. We are still replacing
these as they go bad...

You see, we only use on small field on the whole EEPROM. Problem
doesn't happen every time, and may be worse on some system, and less on
others. Also, some people just don't use the things that often to break
them!

--
Charlie
--
Edmondson Engineering
Unique Solutions to Unusual Problems

 

[Charles Edmondson]

Dummy wrote:

Robert Monsen <rcsurname@comcast.net> wrote in message news:<W8WdnfdK4bC_bLDfRVn-1w@comcast.com>...

Charles Edmondson wrote:

Take a GOOD look at power up and power down sequences. A few years ago,
a vendor of mine was having problems with a similiar situation, where an
EEPROM kept getting programmed to random bits here and there. Seemed
that on start up (this was on a parallel port) there were voltage
glitches that JUST HAPPENED to mimic the programming sequence on the
device, which was not supposed to be field programmable! Since this was
a security dongle, and the bits were sometimes the security ID codes,
this was considered a very bad thing!


Were they actually able to observe this, or was it assumed? Dealing with
hardware/software interfaces, it is quite common for programmers to
blame software bugs on hardware 'glitches'. I've seen this again and
again. It is usually a bug that just seems to come and go, possibly due
to some unrelated change in the software that changes the timing or
place in memory where a random pointer is hitting. I have made a living
out of consulting on these kinds of issues.


So, take a look at what occurs during start up and shut downs, and see
if there are any glitches then that can cause you problems!


Yet another goblin to beware of. Thanks.


Introducing random noise at supply line won't be able to cause any
glitches at EEPROM lines because the noise was riding on the supply.
However, when glitches are introduced to main supply line by creating
a temporary dip of voltage at certain period, glitches can passed
through to EEPROM lines.

Previously, we have been able to see the EEPROM checksum error by
introducing noise to EEPROM directly, bypassing the regulator. So I
reckon that if the glitches get through the regulator, most probably
checksum error will occur. We are checking on that. We thought of
noise, but missed out the glitches.

If that's the root cause, any method to prevent glitches? I guess
regulator is only able to filter the noise that rides on the Vcc. Any
sudden dip in voltage is not recoverable.

For you, this might be a design issue. As power ramps up/ramps down,
different components react differently. Some have internal caps that
make them hold state a little longer than others, or are just more
sensitive to power supply levels. Think about the programming sequence.
What could provide it in your circuit. What could PREVENT it in your
circuit!

I have often found that start up conditions are not fully considered in
design. You just assume that the power comes up all at once, smoothly.
In reality, different voltage rails come up differently. Filter caps
take time to charge up to voltage. Good design takes that into account,
sometimes adding POR circuits to make sure that power is steady before
starting things up, and quick shut down sequences to turn everything off
before the power goes below limits. It's like preventing race
conditions and logic glitches. Sometimes, you just have to take a good
look at the failure modes...

--
Charlie
--
Edmondson Engineering
Unique Solutions to Unusual Problems

 

[Robert Monsen]

Charles Edmondson wrote:

For you, this might be a design issue. As power ramps up/ramps down,
different components react differently. Some have internal caps that
make them hold state a little longer than others, or are just more
sensitive to power supply levels. Think about the programming sequence.
What could provide it in your circuit. What could PREVENT it in your
circuit!

I have often found that start up conditions are not fully considered in
design. You just assume that the power comes up all at once, smoothly.
In reality, different voltage rails come up differently. Filter caps
take time to charge up to voltage. Good design takes that into account,
sometimes adding POR circuits to make sure that power is steady before
starting things up, and quick shut down sequences to turn everything off
before the power goes below limits. It's like preventing race
conditions and logic glitches. Sometimes, you just have to take a good
look at the failure modes...

Typically, parallel eeproms have active low write enable and chip select
pins. If those pins are slow to come up, I guess it can cause problems.

However, one typical example is the atmel parallel eeproms. They require
an 0xAA, followed by an 0x55 to be written to special addresses before
they'll go into write enabled mode. The address pins need to be set to
1555 for the 0xAA, and 0xAAA for the 0x55. Getting this to happen
because of a startup seems incredibly far-fetched.

There is also a set of hardware features that protect against
inadvertent writes. The AT28BV64B has a power on delay of 10ms after Vcc
comes up; thus, these glitches would have to be at least 10ms. If OE is
low, writes are inhibited; thus, the glitch would have to be restricted
to the WR and CE pins. If either CE or WE are high, writes are
inhibited; thus, the glitch would have to be on both of these, but not
on OE. Also, pulses of less than 15ns on either WE or CE won't initiate
a write cycle. After this dance, one has to go through the software
programming sequence to get it to really go into write mode.

Again, startup writes to these things sounds incredibly far-fetched.
Perhaps after trillions of power cycles inducing random noise (1,000,000
monkeys?).

I'm guessing your example eeprom wasn't one of these, and was protected
in some other way. Either that, or the chip firmware was flawed, and the
sequence above could be circumvented in some situations.

The OP hasn't indicated what EEPROM he is using, or what kind of usage
(whether it's getting programmed in the field or not). Thus, we are all
speculating without any real information.

--
Regards,
Robert Monsen

"Your Highness, I have no need of this hypothesis."
- Pierre Laplace (1749-1827), to Napoleon,
on why his works on celestial mechanics make no mention of God.

 

[Dummy]

Robert Monsen <rcsurname@comcast.net> wrote in message news:<Xe-dnQzHGNTX_bLfRVn-tQ@comcast.com>...

Charles Edmondson wrote:

For you, this might be a design issue. As power ramps up/ramps down,
different components react differently. Some have internal caps that
make them hold state a little longer than others, or are just more
sensitive to power supply levels. Think about the programming sequence.
What could provide it in your circuit. What could PREVENT it in your
circuit!

I have often found that start up conditions are not fully considered in
design. You just assume that the power comes up all at once, smoothly.
In reality, different voltage rails come up differently. Filter caps
take time to charge up to voltage. Good design takes that into account,
sometimes adding POR circuits to make sure that power is steady before
starting things up, and quick shut down sequences to turn everything off
before the power goes below limits. It's like preventing race
conditions and logic glitches. Sometimes, you just have to take a good
look at the failure modes...


Typically, parallel eeproms have active low write enable and chip select
pins. If those pins are slow to come up, I guess it can cause problems.

However, one typical example is the atmel parallel eeproms. They require
an 0xAA, followed by an 0x55 to be written to special addresses before
they'll go into write enabled mode. The address pins need to be set to
1555 for the 0xAA, and 0xAAA for the 0x55. Getting this to happen
because of a startup seems incredibly far-fetched.

There is also a set of hardware features that protect against
inadvertent writes. The AT28BV64B has a power on delay of 10ms after Vcc
comes up; thus, these glitches would have to be at least 10ms. If OE is
low, writes are inhibited; thus, the glitch would have to be restricted
to the WR and CE pins. If either CE or WE are high, writes are
inhibited; thus, the glitch would have to be on both of these, but not
on OE. Also, pulses of less than 15ns on either WE or CE won't initiate
a write cycle. After this dance, one has to go through the software
programming sequence to get it to really go into write mode.

Again, startup writes to these things sounds incredibly far-fetched.
Perhaps after trillions of power cycles inducing random noise (1,000,000
monkeys?).

I'm guessing your example eeprom wasn't one of these, and was protected
in some other way. Either that, or the chip firmware was flawed, and the
sequence above could be circumvented in some situations.

The OP hasn't indicated what EEPROM he is using, or what kind of usage
(whether it's getting programmed in the field or not). Thus, we are all
speculating without any real information.

Atmel EEPROM AT25128 is used in the radio. Radio programming was
performaed in the field but EEPROM checksum error did not happen after
radio programming. It happened during normal operation of radio. Of
course, the EEPROM checksum error message won't appear during
operating the radio because the checksum will only be checked during
radio startup. There'll be read/write operation involved at EEPROM
while operating the radio.

 

[Robert Monsen]

Dummy wrote:

Atmel EEPROM AT25128 is used in the radio. Radio programming was
performaed in the field but EEPROM checksum error did not happen after
radio programming. It happened during normal operation of radio. Of
course, the EEPROM checksum error message won't appear during
operating the radio because the checksum will only be checked during
radio startup. There'll be read/write operation involved at EEPROM
while operating the radio.

Ok, this is an SPI serial eeprom. It has various levels of hardware
protection, but it also has a software write disable command. You first
enable it with a write enable, make your change, and then disable it.
Are you disabling it after each write?

The spi interface is such that if there is noise on the clock pin, it's
conceivable that if you left the thing selected, and in write mode, that
it could write a random byte. The write opcode is the cleverly chosen
0000x010. Clocking the thing enough times to output the address and data
(then raising CS at just the right time) might cause problems.

However, I'm still guessing it is a software problem. You are writing
the bad data. You can prove this to yourself by keeping a shadow copy of
the data elsewhere in the eeprom, assuming there is enough room. If it's
bad in both places, you are writing it.

Also, disable writes after you change the data, if you aren't already
doing it.

One other idea is that if you continually rewrite the same cell, it can
run out of lives. The cells will only last for a certain (large) number
of writes. Flash file systems typically rotate the flash pages to
prevent this sort of problem. If, for example, you are putting the
checksum in the same place, and rewriting it again and again on a moment
to moment basis, you can cause the cell to fail.

--
Regards,
Robert Monsen

"Your Highness, I have no need of this hypothesis."
- Pierre Laplace (1749-1827), to Napoleon,
on why his works on celestial mechanics make no mention of God.