AVR-Chat

At 11:19 PM 9/19/04 -0400, you wrote:
>At 10:25 PM 9/19/04 -0300, you wrote:
> >         I have a circuit using an AT90S2313 working on a very noisy
> >environment and subject to program 'crashes' sometimes.
> >         The Watchdog is very efficient recovering from crashes, but
> >I'm having a corruption on the EEPROM contents.
> >         What is the best method of saving some bytes (2) in the internal
> >EEPROM and getting them back without corruption? Is there some sort
> >of FEC applied to memories?

As promised the reference to the National app-note. It's AN482 on error 
detection and correction.  I've used their techniques on external ee in a 
noisy environment.  These are aimed more at single bit wearout type errors 
though, or single bit data stream corruption.  As a final resort detection 
of corruption it has a use but I think the base problems are not addressed 
by this.  The errors I've seen (and I have to say they weren't on internal 
atmel parts) appeared to be more extensive.  The approaches we took were

  - multiple copies of infrequently changing data (such as parameters), 
with fletcher checksums to detect changes.
  - Hamming code protection of frequently changing data (such as timers)
  - no protection of error codes

Even with this protection all copies of the parameters would occasionally 
get corrupted.  Further efforts led to
  - many code reviews looking for SW failures.  The SW would only turn off 
write protection for the time of the update of whatever location was being 
updated (and of course in the case of multiple copies the checksum/crc of 
the copy being updated would be updated before any other copies were modified)
  - extra decoupling capacitors added to the EE.

Each of those helped.  Part of the problem at this point is the error rate 
was small.  Only a few units a year.  In some cases the parameters would be 
customized so the default parameters would be the ones the customer would 
use and so any errors that would occur would not even be noticed.  Two more 
things were done though
  - the PC board was converted to four layers with power and ground planes. 
It appeared from the returns that this probably reduced the error rate by a 
factor of 2.
  - new designs switched to FRAM from EE.  The write time on FRAM is so 
much faster than the write time for EE (100ns as opposed to 5mS) that the 
window of vulnerability where the device is write enabled is very much 
shorter.  It looked like this was also making a difference but I wasn't 
around long enough to see enough data to be sure.

Some designs I've seen only write to non-volatile storage when the noise is 
low and they can be sure of power, essentially making parameter updates a 
task that can only take place when the equipment isn't running.

Note that the long write time of the EE means that if you write to the EE 
during normal operation you must be able to detect the power failing at 
least 5mS before you lose power to the micro and EE, otherwise you will 
interrupt in the middle of a write.  None of the EE for which I've read the 
documentation will guarantee what happens when you do that and if I recall 
correctly some of them explicitly warn that doing so may corrupt all of the 
EE contents.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III