This App Note looks interesting. Unfortunately I have had no luck locating
it on national.com using variations of the search 'an-482 error detection
correction.
Could you send a link to the place we can get it from.
Thanks,
Ivan
----- Original Message -----
From: "Robert Adsett" <subscriptions@aeolusdevelopment.com>
To: <AVR-Chat@yahoogroups.com>
Sent: Tuesday, September 21, 2004 6:06 AM
Subject: Re: [AVR-Chat] Saving in EEPROM without corruption?
>
> 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
>
>
>
> ------------------------ Yahoo! Groups Sponsor --------------------~-->
> Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
> Now with Pop-Up Blocker. Get it for free!
> http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/dN_tlB/TM
> --------------------------------------------------------------------~->
>
>
> Yahoo! Groups Links
>
> <*> To visit your group on the web, go to:
> http://groups.yahoo.com/group/AVR-Chat/
>
> <*> To unsubscribe from this group, send an email to:
> AVR-Chat-unsubscribe@yahoogroups.com
>
> <*> Your use of Yahoo! Groups is subject to:
> http://docs.yahoo.com/info/terms/
>
>
>
>
MSGTAG has notified the sender that you have read this message.