Arduino Board malfunctioning

arduino

I cannot seem to upload sketches to my Duemilanov.

On Ubuntu, the arduino terminal displays: avrdud: stk500_recv(): programmer is not responding
On Windows: avrdude: avrdude: stk500_getsync(): not in sync: resp=0x00

Tried reburning the bootloader:

avrdude: error: could not find USB device "USBasp" with vid=0x16c0 pid=0x5dc

.

When I attempt to upload a new sketch, the Arduino RX/TX lights do not do anything. The "L" LED blinks once and that is all. While the IDE is "uploading" the new sketch, the Arduino begins running the previously loaded sketch as if completely ignoring the new data.

Sometimes the IDE will get stuck "uploading" and the TX light on the board will blink indefinitely.

When I first plug the board in to my PC, the "L" LED blinks 7 times after TX/RX blink a few times.

The most strange thing I have figured out is that if I completely unplug all of the data lines that are connected to the board it works fine. I am able to upload without a problem so long as nothing is plugged into the board (not even a 5V, GND, or digital pin).

I tried this and it works fine: http://forum.arduino.cc/index.php?topic=73748.0

Any suggestions? I was literally just using it without a problem 24 hours ago.

Arduino 1.0.5

Duemilanov

Best Answer

You mention that you are running the the AVR 5v and GND line to the breadboard, if your circuit is drawing more than a little bit of current (powering amplifiers and other active elements) you should use a separate regulator, dips in Vcc, especially at power up, when the bootloader is trying to write the flash, can prevent the read/write operation from completing fully with the application section getting corrupt (not properly written sketch) or the avr loading/executing the wrong instruction from the bootloader (preventing application write). If your data lines are being used to source significant current (multiple LED's) you should also reconsider your circuit layout for the same reason. Since the bootloader is working properly when disconnected from the breadboard, and you've already excluded other problems like the tx/rx line being interfered with by outside devices (by connecting something to pin0) and random resets.

In the atmega datasheet (page 278) there is a buried section that states

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. If there is no need for a Boot Loader update in the system, program the Boot Loader Lock bits to prevent any Boot Loader software updates.

  2. 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.

  3. 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.

In the worst case this can result in the bootloader flash section getting corrupt.

Related Topic