Arduino Board malfunctioning

Question

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

Answer 1

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.

Answer 2

The question is a little short on details - but here is a most likely cause/solution.

if I completely unplug all of the data lines that are connected to the board it works fine

Possibility "A": You probably have something plugged into pins 0 and 1 (RX/TX) on the Arduino. Hence, removing it allows the bootloader to receive data without additional device chatter ONLY when you unplug pins 0/1.

If this is the case (and a photo or diagram of your setup would help) - you can try to add a switch between the external device and the RX line on your Arduino. This will make it easier to isolate the line for programming. A mercury switch is one option, position it in a way that it is "closed" in normal position (device connected) - tip the box/board over and the switch disconnects, allowing programming.

Possibility "B": The reset line is wired to something else which prevents the bootloader from activating when you send the data (RTS reboot). If unplugging from the reset line works, then this is your problem. Alternately press and hold the RESET button on the Arduino then begin the upload - release the RESET button when AVRdude begins transmitting. This will wake up the bootloader and it will catch the incoming data.