EEPROM checksum error

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.

So the problem happens most likely when the user powers off the radio whilst the EEprom is being written to ! Supply rails fall in an uncontrolled manner

That creates questionable data and hence a checksum error.

I got over this one by using multiple writes to different locations and comparing contents.

Graham

the EEprom is being

comparing contents.

Or, write to the EEPROM as a circular buffer (assuming that the length of the information to be stored is less than half the EEPROM length). On bootup, fetch the highest indexed data block that has a valid checksum. If the user does a store-to-EEPROM and then quickly turns off the power, the startup values revert to the last good set.

--
Rich Webb   Norfolk, VA

How do I introduce glitches to supply line? Pulse generator can be used, but it doesn't have enough current capability to turn on the radio. I coupled the pulse through a 0.1uF cap to supply line, but the amplitude was greatly reduced when measured at radio supply line.

Right, there are also error correcting codes that can be used. Total redundancy, with three copies, is the ultimate in error correcting codes. I believe I recall that the space shuttle software uses that scheme to verify results; however, for them, they use 3 independently designed and tested systems, and a voting scheme.

--
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.

He needs to keep a read-verify table in EPROM that records each write was verified by read back. Then the checksum error does not fail power-on self-test when a verify bit was not set. He can encode the verify recording any number of ways to put the probability of false verify bit setting at 1e-24 if he wants.

Isn't that typical. And we're supposed to feel sorry for these people losing their jobs to overseas operations? No way- may they die a slow death and never return- the US blew it.