0
\$\begingroup\$

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

\$\endgroup\$
10
  • 1
    \$\begingroup\$ I would say a bootloader corruption, since stk500 refers to the ISP that the bootloader is emulating. But the fact that you can upload fine if you strip the board is strange. Considering that there is an LED hardwired to a digital IO pin on the board, you can't "unplug everything", so what did you have plugged in before? Do you have an ISP available to use to reload the bootloader? \$\endgroup\$
    – crasic
    Jul 30 '13 at 4:57
  • \$\begingroup\$ I don't. I was looking to purchasing one though; is there a particular one you suggest for beginning? I really am not sure which to get. I mean't that if I unplug all of the data pins then it will upload fine (on Windows, Linux still does not work). I was using the 5V, GND, two Analog pins, and 8 Digital pins (2 were PWM). \$\endgroup\$
    – sherrellbc
    Jul 30 '13 at 5:03
  • \$\begingroup\$ I also tried to reburn the bootloader via the IDE, but had the same problem. Presumably because the same interface is required to upload the bootloader. It was worth a try. I researched solutions and someone succeeded after doing that. I actually went ahead and ordered an UNO. I had been thinking about it anyway but needed the reason. I also read that someone solved a similar problem by using a second arduino to 'flash' .. etc etc. I don't remember what it was exactly and will have to read more into it, but it's also worth a try. \$\endgroup\$
    – sherrellbc
    Jul 30 '13 at 5:06
  • \$\begingroup\$ The bootloader talks to the IDE to start uploading the sketch, Its not possible to rewrite the bootloader sector without overwriting the code doing the loading. I've used the USBtinyISP with success, its very cheap too. \$\endgroup\$
    – crasic
    Jul 30 '13 at 5:10
  • 1
    \$\begingroup\$ What did you have connected to the board before, what do you mean by "unplug the data pins" are you removing the header from the board? \$\endgroup\$
    – crasic
    Jul 30 '13 at 5:11
2
\$\begingroup\$

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.

\$\endgroup\$
1
\$\begingroup\$

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.

\$\endgroup\$
2
  • \$\begingroup\$ I do not have a 'reset line.' I have read that the reset pin should be connected to a resistor to ground, but have also read this is not necessary. So I have never included it and have never had problems before this either. I have also tried your solution B. I held the reset button until the IDE said "uploading" and released it. Alternatively, I also grounded the reset pin and repeated the same process. Nothing seems to work. \$\endgroup\$
    – sherrellbc
    Jul 30 '13 at 15:35
  • \$\begingroup\$ Interestingly, though, I did have something wired into pin 0. Although, I tried removing this pin and uploading but it did not work. Could this have corrupted the bootloader, perhaps? \$\endgroup\$
    – sherrellbc
    Jul 30 '13 at 15:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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