Arduino Noob Can't Upload, please help.

I'll try not to be the boring noob can't upload post. I've read the setup & troubleshooting guide and several forum posts. I'm running the arduino 0018 software and installed the 2.06.02 drivers on Windows 7 Enterprise x64. I've uninstalled and reintalled Java. My board is a Duemilanove w/atmega328. Upon plugging in the USB cable into any of the computers USB ports I have a green LED and blinking red D13 LED.

In the arduino application I've selected the correct Board and COM port based on Device Manager reporting USB Serial Port (COM3). Device Manager also reports a USB Serial Converter suggesting to me the FTDI drivers; BUS and PORT level have been properly installed (and reinstalled).

After loading the Blink sample sketch into the arduino application, shortly after pressing the upload button the RX LED blinks 3 times (further suggesting to me the USB communications are functioning to some degree) then after a longer delay I get

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

If it is helpful, pressing the reset button shows some activity on the RX and TX LEDs then the D13 LED resumes blinking. I saw that this board has auto reset but I tried some reset/upload timing and it didn't help.

I have not installed the XP compatibility mode yet but will do so if anyone thinks my Windows 7 x64 environment is an issue. I don't know if USB ports are supported in the XP VM but I could find out.

Additional info, I saw the bit about verbose in the user config file the I shaw the bit about simply holding down shift when clicking upload. Here is my output. (While troubleshooting I've changed the USB port to COM1 since the previous post)

avrdude: Version 5.4-arduino, compiled on Oct 11 2007 at 19:12:32 Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/

System wide configuration file is "C:\Program Files (x86)\arduino-0018\hardware/tools/avr/etc/avrdude.conf"

Using Port : \.\COM1 Using Programmer : stk500v1 Overriding Baud Rate : 57600 avrdude: ser_open(): setting dtr avrdude: Send: 0 [30] [20] avrdude: Send: 0 [30] [20] avrdude: Send: 0 [30] [20] avrdude: Recv: avrdude: stk500_getsync(): not in sync: resp=0x00 avrdude: Send: Q [51] [20] avrdude: Recv: avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51

avrdude done. Thank you.

The USB Serial Port properties are 57600, N81 No Flow Control

I've sent off a query to the eBay supplier to see if this really does have the bootloader. The add says "Bootloader ready". Technically any of the chips are Bootloader ready so I assume this is a rough translation of "Already programmed with bootloader". Fingers crossed.

Just installed the software and drivers on my Dell E6500 laptop with Windows 7 Enterprise x64 with the same results :'(. Beginning to think Windows 7 x64 is the problem.

Upon physical inspection of the PCB it appears their may be a solder bridge between pins 25 & 26 on the FTDI chip. I’m going to go look for a schematic to see if this is intended. Any help is still appreciated.

We also just tried installing the arduino software and FTDI drivers on my Son’s Windows XP system with all the same results. Beginning to think I have a bad board or bad bootloader. ::sigh:: Par for the course for me this week.

Found the schematic and found that pins 25 & 26 should be common so no issue with solder bridge. I guess that leaves me back to comm errors or bootloader. I didn't check baud rate on son's XP computer. Has anyone else had to do that or is that what is means when it says overriding baud rate to 57600?

I'm really hoping this turns out to be a stupid Windows configuration issue. This shouldn't be this hard and I don't want to turn everyone at the University off on these boards. I guess when you buy on eBay...

I am getting the same error.

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

I only get it on my main computer running windows 7 x 64. My other computers handle it fine. I am running windows 7 on another and it seems fine, but not sure if 32 or 64.

Any advice?

Have you tried running the uploader in compatibility mode? I haven't used win7 myself, but you should be able to tell it to emulate XP when running a programme. Try right click and look for options (you might need to be logged in as admin).

I'm pretty sure I've ruled out the Win 7 x64 by trying this on my Son's XP x86 desktop. I'm going to try an XP x86 desktop at work today to see what happens. If it fails again I'll feel I've pretty much ruled out Win 7 x64 issues.

I tried again with, yet again, identical results on a fourth computer, with a fresh install of Windows XP. That's four different computers, two Win 7 x64, two Win XP x86, four different motherboards. I'm pretty sure I've ruled out a computer side issue or I'm making the same noob mistake x4.

Fortunately the eBay seller is responding to my inquiries so I'm looking forward to a somewhat satisfactory outcome (not happy about paying return shipping to Hong Kong and will definitely be making sure a new chip with bootloader and shipping isn't cheaper). :-/

Today I ordered a new ATMega 328 chip w/ arduino bootloader. I'm going to see if I have a fried chip or a bad board.

::sigh:: I got the new chip today and was able to upload... once. After the first upload though it is back to the same problem as the original chip. I've tried alternating between the original chip and the new chip with no difference. I noticed the Red LED blink rate was different between the two chips. Is the blinking LED a function of the boot loader or someone loading the Blink sketch for testing?

I'm not missing any steps am I? I change the delay value in the Blink sketch, compile it then upload it to the Arduino. Based on what I saw, the board responded to the auto reset the on the first upload but doesn't appear to be responding to resets after the first Blink sketch upload.

The first time I just hit the upload button the Red LED quit blinking, there was a lot of RX/TX LED activity then I got the Upload complete and the Red LED started blinking again. After I regained my composure from my first successful Arduino upload, I changed the timing on the delay, clicked compile then clicked upload. This time the Red LED just kept blinking away, I saw the RX Led blink three times, just like I've explained before.

I've tried playing with hitting the reset switch and hitting the upload button but frequently it gets upset when the USB port goes away as part of the reset.

It almost appears as if uploading the sketch is messing up the bootloader. I'm thinking about buying one of the parallel programmers so I can reprogram the bootloader onto the chips.

Anyone every run into this before? This shouldn't be this hard should it?

Im having the same problems With the Arduino Pro and a separate USB to Serial converter. Ive also tried many of the same steps as LinhartR and have had no success. Any help would be appreciated.

OK I don't give up easy. I have another Duemilanove board on the way (for once I'm working with a pretty decent eBay seller). I'm wondering if the boot loader version is supposed to match the IDE version. I noticed arduino version 0018 has a burn boot loader with arduino as ISP option. I've tried this a few times but it seems to use the same protocol as the sketch upload so I'm not surprised to see the same failure. I'm wondering if the atmega 328 chips I'm getting have older versions of the boot loader that aren't compatible with this version of the IDE. I think when the new board comes in this will be the first thing I try

I Manged to get mine working! I'm not sure if this will help you LinhartR, but i had power my Arduino directly from the USB to serial converter, then manually reset the board as i trying to upload the blink sketch.

It seems that i have to manually reset the board each time as well.

Spunkmyre, I'm not sure I understand. I'm powering my arduino board from the USB port power. Are you using a USB to serial converter and getting power from that? You are making me wonder, the one thing I haven't tried in all this is a powered USB hub. Perhaps out of all four computers I've tried this on the USB ports are supplying marginal power foe the board. Hard to explain why it did work once in this scenario though. I may try getting a plug for the external power port on the board and try that too.

One other thing I'm noticing is the delay between pushing the reset button and running, what I'm assuming is the Blink sample sketch, is very short. Based on what I'm seeing from the RX/TX LEDs it appears the program has been running for several seconds before there is any activity on the USB port. This would explain why the upload fails because the bootloader has stopped listening on the USB port and is just running the sketch. I'm running a reasonably high end dual core AMD system so I can't believe performance is an issue.

I'm not using a USB hub, but since i purchased the Arduino pro it didnt come with a USB converter, so i have to use a separate module. At first i was trying to power the Arduino from a separate power supply but when i coupled the grounds together i was able to upload code, but i still had to manually reset the board. A USB port with marginal power could cause a similar problem.

*Performance should not be an issue, but depending on the USB converter, you will have a bit of a delayfrom when you send the code, to when it is actually sent to the board, and there is were the problem is. The protocols have to poll and respond to each other to synchronize properly.

Today I tried the powered USB hub. Didn't make any difference. I also tried the loop back test, placing a jumper wire between D0 & D1 and starting the serial monitor from arduino program. Everything I typed in the send box was echoed below. This tells me communication to the FTDI chip is working but not necessarily to the atmega chip. I'm pretty sure I saw on the schematic that one of the serial port flow control lines is used for the auto-reset function. Although I've seen it work once it could still be intermittent on my board either on the FTDI chip or the atmega chip could be ignoring the input. In either case, I should have another Duemilanove here in a few days and hoping I will have better luck.

One thing I did notice during the loopback is it didn't work initially. I noticed the baud rate was set at 57600 and remembered seeing a post about the baud rate for the atmega 328 being 19200. I changed the baud rate on the serial monitor and it started working. Thinking I had found the problem and looking at the "shift-upload" output from earlier in this post you can see where it is overriding the baud rate to 57600 for the upload. So, I edited the boards file and changed the baud rate to 19200. I did the "shift-upload" to confirm it was using the new setting but it hasn't solved my problem.

I don't see how people who are using the USB interface can play with the timing of the reset because at least with Windows, this causes the USB port to close and arduino/avrdude reports a communication error.

Was I under a false impression that the "L" LED on the board was the same as plugging in an LED on D13. I assumed this was why it was safe to plug in another LED, presumably in parallel with "L" LED, sharing the current limiting resistor. I've also never been sure if the blinking "L" LED was a function of the bootloader or a remnant of the "Blink" sketch used as a final QA for the board.

I didn't see where I documented my Java version, only that I had reinstalled it.

Java version 6 update 20

Hooray! Today I have joined the ranks of Arduino programmers. The problem was, after all that pain, a bad Duemilanove board. I got the replacement board today from my eBay seller and it has repeatedly accepted uploads with different delays for the Blink sketch.

I also tested the original atmega chip from the bad board and the spare chip I ordered to test the bad board. They both worked fine.

Anyone want to buy an assembled USBtinyISP kit? Not really, I'll still want to program atmegas without the bootloader or maybe quick start bootloaders or...

:D