Yahoo Groups archive

AVR-Chat

Index last updated: 2026-04-28 22:41 UTC

Message

Re: [AVR-Chat] Saving in EEPROM without corruption?

2004-10-02 by MuRaT KaRaDeNiZ

AT90S2313 micro had been a notorious microcontroller
in terms of its EEPROM data content reliability. Try
new ATtiny2313 micros, they have a real built-in BOD
circuitry. Some of the EEPROM data loss issues come
from non-existence of a BOD circuit.

Hope this helps.

Murat Karadeniz
http://www7.brinkster.com/mukas/



--- Robert Adsett
<subscriptions@aeolusdevelopment.com> wrote:

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



		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.