[Noisebridge-discuss] arduino self-corruption?

Daniel Pitts coloraura.com at gmail.com
Thu Sep 6 17:03:38 UTC 2012


On 9/5/12 9:11 PM, Jake wrote:
> does anyone here have experience with an arduino "bricking" itself or 
> otherwise corrupting its own program?
>
> Reloading the bootloader with an ISP programmer brings it back to 
> normal, but this problem is not supposed to happen.
>
> it could have something to do with low power supply voltage?
>
> I am trying to figure out how to prevent this from happening.
It might be flash corruption due to low voltage, though somehow I doubt 
that.  Just in case:

 From the ATMega328 specs (available at 
<http://www.atmel.com/Images/doc8271.pdf>)
> 26.2.3 Preventing Flash Corruption
> During periods of low VCC
> , the Flash program can be corrupted because the supply voltage is too 
> low for the CPU
> and the Flash to operate properly. These issues are the same as for 
> board level systems using the Flash, and the
> same design solutions should be applied.
> A Flash program corruption can be caused by two situations when the 
> voltage is too low. First, a regular write
> sequence to the Flash requires a minimum voltage to operate correctly. 
> Secondly, the CPU itself can execute
> instructions incorrectly, if the supply voltage for executing 
> instructions is too low.
> Flash corruption can easily be avoided by following these design 
> recommendations (one is sufficient):
> 1. Keep the AVR RESET active (low) during periods of insufficient 
> power supply voltage. This can be done by
> enabling the internal Brown-out Detector (BOD) if the operating 
> voltage matches the detection level. If not,
> an external low VCC reset protection circuit can be used. If a reset 
> occurs while a write operation is in progress, the write operation 
> will be completed provided that the power supply voltage is sufficient.
> 2. Keep the AVR core in Power-down sleep mode during periods of low 
> VCC. This will prevent the CPU from
> attempting to decode and execute instructions, effectively protecting 
> the SPMCSR Register and thus the
> Flash from unintentional writes.




More information about the Noisebridge-discuss mailing list