I have a pretty complicated setup: an ATMEGA328p chip (found in the Uno, Duemilanove, etc.) on a Diavolino board (from EvilMadScientist) running at 8 MHz (instead of the normal 16 MHz). This should be basically the same thing as the 3.3V arduino pro from the code's point of view. On top of this is a custom shield including a bunch of digital and analog devices with SPI, I2C, and serial interfaces.

This is supposed to run for days or weeks at a time. In normal conditions--on the ground outside--it does fine. However, in two recent tests, it lost its program and stopped working. One of these was in a cold low-pressure chamber (-40 C/F). The other was outside mounted on a flying quadcopter. Reprogramming it fixed the problem; before reprogramming, neither a reset nor power-cycling would get any response from it.

Has anyone ever heard of an arduino bricking itself like that? My best idea for how this could happen is that somehow the chip was put into a state where it treated incoming serial data as a new program to run. Also, I'm speculating that connections between the two boards could have been disrupted by thermal contraction or vibration in those tests.

Thanks for any help!

  • Are you using the watchdog timer at all? It would be virtually impossible for random serial data to be treated as new code.
    – Nick Gammon
    Aug 26, 2015 at 21:44
  • 1
    According to the datasheet it will operate at between -40 °C and 85 °C. -40 C/F - I'm not familiar with the temperature unit "C/F".
    – Nick Gammon
    Aug 26, 2015 at 21:46
  • Did you disable brownout detection?
    – Gerben
    Aug 27, 2015 at 9:33
  • 1
    C/F just meant it's at both -40 C and -40 F because those are the same. I don't know anything about the watchdog timer, so I would assume I'm not using it.
    – Vulcan
    Aug 27, 2015 at 23:00
  • And, I did not disable brownout detection.
    – Vulcan
    Aug 27, 2015 at 23:01

1 Answer 1


I would suggest that you reproduce the issue and then use a device capable of reading the flash, to confirm that it's still identical to the .hex file that was used to program the board.

I know that the AVRDragon can do it and maybe also cheaper USB ISP programmers can do it too.

But it seems that you are not alone.

Flash memories like those used in uC work by trapping electrons in wells of charge, so that they pseudo-permanently affect the silicon.

Very low temperatures can change the properties of the insulation, letting many more electrons than usual to escape.

Try to wrap the board in a thermal airtight insulator, possibly providing local heating. That should solve your problems.

  • Thanks! Any idea how the quadcopter failure could have happened? Could vibration somehow cause a similar effect?
    – Vulcan
    Aug 27, 2015 at 23:08
  • I doubt vibration is the cause. Do you have any strong electromagnetic field nearby the processor or any of the cables? Or, more likely, it's a different problem. Aug 27, 2015 at 23:15
  • Yes, the quadcopter has four brushless motors and two radio transmitters. Could interference from those really disrupt the flash memory?
    – Vulcan
    Aug 28, 2015 at 15:46
  • As I wrote, most likely not. But can you reproduce the problem with the quadcopter? Because it should be easy to remove each potential source of disruption (motors, radios) and see if the memory is still corrupted/wiped. Aug 28, 2015 at 15:49

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.