AVR Freaks

Are you using a bootloader? Maybe you get a power glitch and the bootloader erases flash, and sits there waiting for the new program to start coming down the wire?

I agree, I have had some very curious things happen to processors operating at brownout conditions. In one particular instance, an MSP430 managed to rewrite flash, which is very hard to do (there is a lockout magic-key register you need to write a valid value to in order to run the peripheral).

My early projects kept suffering from EEPROM corruption on startup, despite following the extensive advice from Atmel. A clean on-off switch and a decent size cap across the supply help too.

Since they added the BOD functions and the timeout on writing EEPROM, things seem to be OK.

I think that some individual ICs are more susceptible than others too!.

When supply power is dropping, there is almost always a ramp down. Steep or shallow, it doesn't make much difference. Take a time slice of that ramp say every millisecond. Note that your AVR may be rated to, say, 2V Vcc min.

During each of those slices, the AVR executes many instructions. As you get to the 2V level, everything is still traveling along nicely.

Once you get below the rated min supply voltage, at some point pieces of the AVR are going to give up and not run properly. I cannot tell you which subsystem will fail, and at exactly what supply voltage level.

We can tell you that on e of the common symptoms is that an EEPROM write is triggered. And that is to the EEAR address. If EEAR "dies" to 0 first, then address 0 of EEPROM will be wiped out. If not, it will be whatever address EEAR is pointing to.

Other subsystems may also exhibit "faulty" operation when run below spec. The EEPROM is noticeable because the evidence is left behind. One could probably construct a scenario with different legs of a transistor bridge on different AVR I/O ports and one dies before the other, causing a short in the bridge. Does that mean the AVR's I/O ports are "fragile"?

The BOD is there to prevent the microcontroller from >>attempting<< to run when in an out-of-spec situation. Use it--AFAIK every AVR model has one, and it works fine. So it costs nothing. As mentioned above, we all had external devices for that function on our production designs before the internal BOD became commonplace. (Mega8? CRS)

I've always felt that the byte-writable EEPROM on the AVR is one of the nicer features.

Lee

"known fact", and tribal knowledge, and similar?  I'll agree.

Randomly?!?  Not so much.  There is nothing random about it.  Without an appropriate BOD enabled (and I'd really like to explore the claim in #26 that it in fact was/is enabled at an appropriate value), and the supplyV drops below a safe level, and with no BOD the AVR keeps trying like a steer, and one of the things that happens is that the EEAR register(s) cannot hold their value, and then an EEPROM erase/write operation is carried out at address 0 instead.