Communication Error During Program Download

I have a Arduino Duemilanove with an ATMEGA 328. I tried uploading a program I wrote to the board, and I ended up with the following error:

avrdude: stk500_getsync(): not in sync: resp=0x30
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51

It seems from reading some of the other posts on this forum that a lot of people have ended up with this error message, and for many different reasons. It apparently is an indication that there is a communication problem, but after trying a number of things, I still can't get the IDE to communicate with the board properly.

Here's what I know:

(1) I know for sure that I am operating on the correct COM port.
(2) I have the drivers installed for the board and the USB serial port.
(2) My computer recognizes the board when it is plugged in via USB cable, and the RX and TX LEDs briefly flash.
(3) I set the COM port to operate at a BAUD rate of 19200.
(4) The board was pre-built, so there shouldn't be any issues with bad solder joints.
(5) I have the correct type of Arduino selected in the IDE.
(6) I have nothing hooked up to the board while downloading, except the USB cable.
(7) the RX LED flashes every once in a while when a download is in progress, at least until the error occurs.

I tried pulling the chip out of the board and shorting digital I/O pins 0 and 1 together in order to see if I could reflect back a message from IDE serial monitor, but when I did, I only ended up with this error message:

Error inside Serial.serialEvent()
java.io.IOException: Bad file descriptor in nativeavailable
at gnu.io.RXTXPort.nativeavailable(Native Method)
at gnu.io.RXTXPort$SerialInputStream.available(RXTXPort.java:1532)
at processing.app.Serial.serialEvent(Serial.java:215)
at gnu.io.RXTXPort.sendEvent(RXTXPort.java:732)
at gnu.io.RXTXPort.eventLoop(Native Method)
at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1575)

I also tried to upload a new bootloader to the chip via the IDE, but nothing seemed to happen and the IDE just hung forever.

Is it possible that I have a bad chip, or am I doing something else wrong? Thanks in advance to anyone who can enlighten me as to what is going on here. :slight_smile:

Indeed this error message is what you get when there is something wrong.
The clue here is:-
expect=0x14, resp=0x51

This means that something is being received that is not expected. Therefore a whole lot of stuff is working like the communications between the computer and the board. This sometimes happens when the correct type of arduino board has not been selected from the Tools menu.

What do you mean by "setting the baud rate to 19200"? The ATmega328 bootloader operates at 57600, so that could be a problem.

Which operating system are you on? Do you have software running that might be trying to use COM ports? Or firewalls that could be blocking access?

I'm running 32-bit Windows XP. I do have a firewall, but I can find no indication that it is attempting to block anything. To my knowledge, nothing else is trying to use the COM ports.

I set the baud rate of the serial USB COM port to 19200 in the properties of the device in the device manager. The reason I did this was on the troubleshooting page of the IDE, it mentions the following:

If you have a really ancient Arduino board, you may need to change the baud rate at which sketches are uploaded to 9600 (from the normal 19200). You will have to change the speed in the preferences file directly. See the preferences page for instructions on finding the file. Look for the file in your computer and change the serial.download_rate property to match the one in your board. If you have such a board, it's recommended that you burn the latest bootloader (which works at 19200 baud). This can be done with the 'Tools | Burn Bootloader menu item.

After testing my Arduino against another person's board, I found that my first suspicion was correct and my board was bad. Getting another board fixed my issues. That's what is frustrating about communication errors; they can happen for all sorts of reasons.

After testing my Arduino against another person's board, I found that my first suspicion was correct and my board was bad. Getting another board fixed my issues. That's what is frustrating about communication errors; they can happen for all sorts of reasons.

That's why I sometimes recommend proving out the comm path first before trying to upload sketches. This can be done pretty easy by removing the AVR chip from it's socket and then wire a jumper from pin 0 to pin 1. Then launch the Arduino IDE, plug in the USB cable, click on serial monitor. What you type in the monitor's output window should 'echo back' on the monitor's receive window. If that can't be made to work then there is no reason to be trying to upload sketches or running AVRDUDE in standalone mode, etc.

Lefty