AVR-Chat

I recently experienced severe eeprom problems when switching from a mega32
to a mega128.  The solution, it turned out, was to lengthen the start up
time for the external resonator.

This was surprising, to me;  Ever since the BOD has been available I have
had zero eeprom problems (I even have lost the habit of setting the EEPROM
pointer to zero after use and not using the first slot...).

Although I know it is proper defensive programming to do things like
multiple copies, checksums, etc.  I find it is best to figure out what the
problem is and let the hardware do its thing, which is extremely reliable
operation.

I do use checksums (or CRC8 or 16) to flag "empty" memory (or memory layout
that has changed) so the code can initialize it but I can't recall ever
taking a memory hit that wasn't code or hardware setup related (i.e. my
fault).  After figuring out the error the faults always go away.  Sometimes
the fault is obscure (ref, the reminder to disable interrupts while
writing).  But is always turns out to be a code fault.

Take my experiences with a grain-o-salt, your mileage may vary.


-----------
Larry Barello
www.barello.net


| -----Original Message-----
| From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
| Of Gary J. Melvin
| Sent: Thursday, April 06, 2006 8:40 AM
| To: AVR-Chat@yahoogroups.com
| Subject: [AVR-Chat] EEPROM writing with elec. noise
| 
| Hello,
| 
| "Long time listener, first time caller."
| 
| I've taken on an ATmega16-based project.  One of the requirements is
| that I need to write up to 3 bytes of data to EEPROM in a potentially
| electrically noisy environment.  I've never used its EEPROM before, but
| it looks relatively uncomplicated.
| 
| My client has another product in a similar application which has been
| causing them a lot of grief with random EEPROM write errors, presumably
| due to noise glitches.  (They use the built-in Brown Out feature  -
| both trigger settings produced the same results.)  Obviously, this needs
| to be solved with this new product.
| 
| Here's the approach I suggested to them - feel free to shoot it down.
| I've asked them to add a voltage divider before the regulator.  Run it
| through a Schmitt Trigger to an input pin on the '16.  I've also asked
| that they beef up the regulated voltage filtering to ensure at least 50
| mSec of adequate power to carry it through a total drop out of the
| supply.  (8.3 mSec, minimum, per EEPROM erase/write cycle times 3 bytes
| of data = 25 mSec ... then double it for peace of mind.)  Before writing
| the 1, 2, or 3 bytes of data, I'll check the status of the pin - if low,
| I won't do the write(s).
| 
| I'm open to suggestions.  If you have a better approach or a
| bullet-proof algorithm, please enlighten me.
| 
| Thanks!
| 
| Gary.
| 
| 
| 
| 
| Yahoo! Groups Links
| 
| 
| 
| 
|