AVR-Chat

I seem to have found a cure for my EEPROM corruption.
	For those who doesn't read my original message, it is not
that EEPROM address zero corruption due to power brown out 
mentioned by ATMEL

	I have a 2313 working on a very noisy environment and subject
to eventual crashes that corrupt the EEPROM. Any address.
	And I'm not allowed to modify the hardware at this time.

	Well, two 'nops' inserted in the EEPROM write routine seem to 
have cured the problem. See below:

		cli
		out	EEARL, address
		out	EEDR, data
		sbi	EECR, EEMWE
		nop					; Inserted
		nop					; Inserted
		sbi	EECR, EEWE
		clr 	address
		out	EEARL, address
		sei

	In fact, I later changed the two 'nops' for a security test
and jump out to avoid spurious EEPROM writes.

	Mark Jordan


On 2 Oct 2004 at 1:49, MuRaT KaRaDeNiZ wrote:

> 
> 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 
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
>