Go Down

Topic: Random failure to upload code. (Read 1 time) previous topic - next topic

Brian Neltner

I have an arduino demilove (atmega328) running a ported version of liblo that was our own work, and uIP based on the wishield codebase. I am programming it from an Ubuntu 10.04 computer.

I have it able to receive data and such from the wifi network and change the color of my LED light using OSC packets, but when I make updates to the code and try to upload them, about 90% of the time it fails with various errors ranging from "out of sync" to "lost communication" to "not connected". But if I keep hitting "upload" without necessarily even resetting the device, it will suddenly work.

Here are some examples of sequential error messages, after taking off the wishield just in case that is causing an issue:

avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_loadaddr(): (a) protocol error, expect=0x14, resp=0x10
avrdude: stk500_loadaddr(): (a) protocol error, expect=0x14, resp=0x10
avrdude: stk500_recv(): programmer is not responding
Successfully Uploaded
Successfully Uploaded
Successfully Uploaded
avrdude: stk500_recv(): programmer is not responding

and so on. This is all sequential, without any shields, with code that functions when it successfully uploads (i.e. is presumably not somehow hard-locking the arduino if that would prevent programming), and without power cycling or trying to reset the device.

I can only think of two possibilities for this.

1. The arduino bootloader or avrdude have too short of a timeout and don't wait long enough to upload the 17596 byte program before assuming the programmer isn't responding.

2. My code is somehow blocking the bootloader from functioning.

(2) seems unlikely because I have it turn on an LED light on startup. When I start programming, the LED light turns off. Whenever it fails to program, it turns the LED light back on before the arduino software reports successfully uploading the code. This seems to me to indicate that the device is successfully being put into "reset" mode for programming, but is leaving programming mode before it is finished.

Does anyone know how I can check to see if it is a timeout issue in the bootloader or on the avrdude side of things? Or does anyone have alternative ideas as to what the problem could be? I need this to program 100% of the time reliably (or at least 95% of the time).

I tried uploading a smaller, simpler program (1334 bytes) 20 times, and it worked 19 times out of 20. Unfortunately, this doesn't help me distinguish between problems (1) and (2), but it does verify that my programmer in general does work (assuming the one failure was a fluke).

Thanks,

Brian Neltner

To make things weirder, get this.

I upload my small code that works fine. It cycles the LED colors forever in a loop.

Then, I upload my gigantic code that does wifi control of the LED lights through python. It reports "avrdude: stk500_recv(): programmer is not responding".

HOWEVER:

The code is still running! It turns on the red channel on dim until it successfully connects to the wireless network, flashes blue and then off, and then I can control it perfectly from my python script!

What is with the scary error? Is my code uploaded correctly or not? Can I verify the code manually? I know how to do that on a normal atmega, but not inside of arduino...

Grumpy_Mike

It sounds like the auto reset on the arduino is not working correctly or your PC is too slow (or too fast) that it is missing the download window the boot loader opens after reset.
You can try increasing the value of the capacitor from the DTR line to the reset line by soldering another one in parallel. Use as big a non polarised value as you can get. I sometimes use a 1uF here.

Brian Neltner

Wow; I didn't realize there was a power reset startup circuit in there. Capacitor + Transistor + Resistor for delayed powerup?

Ick. As much as I'm not terrified about changing something like this, is there any way to address this in software? If it actually is a capacitor on the reset line that gradually pulls it back up, it sounds like a resounding "no"...

Surely other people have this issue with large programs... and if it's resetting before finishing upload, god knows what the code is that's actually there... =(

Is there *anything* I can do short of soldering a new resistor onto 100+ arduino boards...?

Coding Badly

Quote
Does anyone know how I can check to see if it is a timeout issue in the bootloader or on the avrdude side of things?

You will get details if you hold down the SHIFT key while performing the upload.

Go Up