Has anyone else had instances where an AVR just mysteriously stopped working after several months, but reprogramming it would bring it back?

I'm running a bunch of atmega328's in wireless sensor network. I've now had 3 times (in about a year) when one of them has just stopped working. I'll re-burn the program to it and it'll start working again. It's not always the same unit, so it doesn't seem like it's a defective chip.

That seems like it would be a rather disastrous thing that would keep people from using AVRs, so it's obviously something about my particular circumstances. I was just wondering if anyone else has run into it and might have some pointers.

I'm running at 3.3V off of batteries, so the voltage will sag too low to operate once every couple months and I have to replace the rechargeables. The modules use sleep mode and the watchdog timer to sleep for 60 seconds, take a reading, radio it back to the base station and then sleep again. The modules are arduino compatible, so I haven't flipped the "don't let me re-burn this" bit.

  • \$\begingroup\$ Where you able to identify the problem? We are experiencing similar issues with a similar setup. Did you ever read out the "corrupt" flash memory and compare it to the original HEX contents? \$\endgroup\$
    – Rev
    Commented Jun 25, 2014 at 11:25

4 Answers 4


Are you using BOD? Nasty things can occasionally happen if a chip browns out.

  • 3
    \$\begingroup\$ To clarify, edebill should be using BOD. \$\endgroup\$ Commented Aug 29, 2010 at 1:55
  • \$\begingroup\$ Not using BoD. I'll have to see about adding it. So the scenario here would be that the chip just starts flailing around as the voltage gets too low and accidentally corrupts its own flash? \$\endgroup\$
    – edebill
    Commented Aug 31, 2010 at 13:04
  • \$\begingroup\$ @edebill - On PICs, I've seen that happen a lot in production when BORV thresholds aren't set. \$\endgroup\$
    – J. Polfer
    Commented Oct 15, 2010 at 18:00
  • \$\begingroup\$ What is BOD? Brown Out Detection? \$\endgroup\$ Commented Oct 17, 2010 at 8:03
  • 2
    \$\begingroup\$ Yes, it is Brown-Out Detection. \$\endgroup\$ Commented Oct 17, 2010 at 14:44

Probably the Brown-Out-Detection is the right way to do, but...

I had a software only problem that caused very similar symptoms, though much more quickly. I believe some bad C++ (compiling?) resulted in stack corruption, and the function returned outside of the real program, executing random instructions. I'm not sure exactly what happened next, but the only way to fix it was to reburn the program (apparently some of those random instructions included writing to program memory).

The bug was just a destructor being called at the wrong time. Making the variable global (so it was never destroyed) fixed the problem. The problem was very easily reproducible (took about one minute to trigger), and on very steady power. The particular setup was Arduino+WaveShield using the WaveHC library, but I think this could happen to anyone using C++.

If you prefer low level languages, I accidentally did about the same thing in assembly, but miraculously this never caused anything but sporadic timing problems: most instructions are 2 bytes long, but some are longer, and I foolishly calculated the jump distance myself and jumped into the middle of a 4 byte instruction. It got realigned fairly quickly, but it is not hard to imagine something like this on a rarely used code path causing insanity.

  • \$\begingroup\$ This could also happen with processors which map some of the flash memory into the main memory space. I know at least the dsPIC's and PIC24's do this. If you had a corrupt pointer and the right circumstances you could overwrite flash. \$\endgroup\$
    – Thomas O
    Commented Oct 15, 2010 at 18:58

I've also seen insufficient / poorly placed / missing Vcc decoupling capacitors cause similar effects. Do you have local decoupling as close as possible to the IC? (100nF - 1uF ceramic type is preferred)


Another factor that can cause devices to loss their memory is electro static discharges (ESD).

Placing a few varistors on all the external facing connectors that are subject to exposure can alleviate this issue. I have seen it before in some commercial products based on Microchip PIC microcontrollers, so it is not unheard of.

There are some handy varistors that double as filter capacitors also (in the order of 10-150 pF). Check these out http://www.tdk.co.jp/tefe02/e9c11_avr.pdf

They are small, cheap, and will protect your device. Place them as close as possible to the connectors bringing external signals onto the board, and route all traces immediately away from the connector pins.

  • \$\begingroup\$ Varistors aren't for ESD protection (they are for the protection of surges lasting 10's to 100's of milliseconds); the device's internal diodes are usually enough, but for when it isn't, adding some reverse-biased diodes to either rail (Vdd and GND) usually works, be careful though because this does add capacitance to the IO and can affect high speed stuff. \$\endgroup\$
    – Thomas O
    Commented Oct 16, 2010 at 14:05
  • 1
    \$\begingroup\$ Thomas have a look at the TDK datahseet, these devices are specifically designed for ESD counter measures, and they are proven to work in production for electronic communication devices. We test our devices in house with up to 8 kV ESD and these devices do protect other components. \$\endgroup\$ Commented Oct 16, 2010 at 14:15
  • \$\begingroup\$ You are correct about the additional capacitance, and that does need to be considered. \$\endgroup\$ Commented Oct 16, 2010 at 14:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.