First Upload worked, subsequent ones fails

I am using the DiyDrones Ardupilot board. (newer Duemilanove with ATmega328).
My host is Ubuntu 9.04 Linux.
At my first attempt, I was able to load the standard Ardupilot_EasyStar_V23 sketch, unmodified fr
om download from the project site.
This appears to work - basic functionality corresponds to what is expected from the project docum
entation.
The problem is when I try and upload a new version of the software, having made some edits.

No software has either been installed or uninstalled from my PC.

I have tried a variety of things, from resetting the board before, after etc the upload. In some
cases the returned code differ from 0x2b, but in all cases the upload fails.

Here is a verbose output:

Experimental: JNI_OnLoad called.
Stable Library

Native lib Version = RXTX-2.1-7
Java lib Version = RXTX-2.1-7
Binary sketch size: 15514 bytes (of a 30720 byte maximum)
/home/nigel/drone/arduino-0017/hardware/tools/avrdude -C/home/nigel/drone/arduino-0017/hardware/t
ools/avrdude.conf -v -v -v -v -pm328p -cstk500v1 -P/dev/ttyUSB0 -b57600 -D -Uflash:w:/home/nigel/
drone/ArduPilot23/Source Code/ArduPilot_EasyStar_V23/applet/ArduPilot_EasyStar_V23.cpp.hex:i

avrdude: Version 5.4-arduino, compiled on Oct 22 2007 at 13:15:12
Copyright (c) 2000-2005 Brian Dean, (edited)

System wide configuration file is "/home/nigel/drone/arduino-0017/hardware/tools/avrdude
.conf"
User configuration file is "/home/nigel/.avrduderc"
User configuration file does not exist or is not a regular file, skipping

Using Port : /dev/ttyUSB0
Using Programmer : stk500v1
Overriding Baud Rate : 57600
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Recv: + [2b]
avrdude: stk500_getsync(): not in sync: resp=0x2b
avrdude: Send: Q [51] [20]
avrdude: Recv: + [2b]
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x2b

avrdude done. Thank you.

Any ideas most welcome...
Thanks

It sounds like you may have the wrong board chosen?
I use windows, not familiar with Linux at all.. but I get the same errors when I'm trying to upload to my board when I have a different selection.

I have 2 arduinos, one uses a 168, other uses the 328.. gotta switch em every time.. even with 2 IDE open, if you switch the COM port or board on either, it'll do the same for the other.

Other than that, not really sure! Hopefully somebody else can give you some tips:/

What USB/TTL adapter do you use ?

Auto reset doesn't work with FTDI cables on linux. So either you have to press the reset button at the right moment, or get a better adapter that provides the DTR line. E.g. the "BUB" by moderndevice.com does just that.

Thanks. I used the USB FTDI from the DiyDrones website

http://store.diydrones.com/ProductDetails.asp?ProductCode=TTL-232R-3V3
It uses the FTDI FT232RQ USD - Seriall UART interface chip.
There is a datasheet on the URL. From that I see that the signals provided are GND, CTS#, VCC, TXD, RXD, RTS#.

I will try from XP when I can find a windows machine.
In the meantime, could you be more specific with the reset timing, as I have tried that, and it seems to change the return codes, but still fails...
Thanks
Nigel

I just tried the same with windows XP.
A very similar result - the upload failed, this time with different return codes:
0x00 and then 0x51.
This is using the same FTDI cable.

First you need to set 'build.verbose = true' and 'upload.verbose=true' in 'preferences.txt'. On linux this file is located in '$HOME/.arduino/' , on winblows I think it is now somewhere in the user's appdata folder.

The timing is a bit critical:

In your error messages you've already seen these

avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]

lines. You need to press reset instantly, as soon as you spot the first line of this kind, not later. Maybe you can arrange pressing the reset button just a tiny bit before.

If your problem is indeed auto-reset related, this should fix it. On winblows there is an option you can set in the device manager for COM ports called "RTS on close". This may fix the auto-reset problem.

Personally I switched to other USB adapters, as they come with DTR and just work out of the box.

Thanks, I have this working in Windows. The secret was to add the RTS on Close to the COM5 port then reboot.
Will look into the linux solution later but at present resigned to using windows for this...
Thanks again for the help...