Arduino won't upload

Thanks Louis for pointing that out. I completely forgot that, and obviously the .hex I used was just the serial non-combined.

@RubinGrolsch - the file is up one more level in arduino-usbserial - Arduino-usbserial-atmega16u2-Uno-Rev3.hex like my screen has on it.

Sorry about that...

Hi everyone!

I do have the same problem! It seems I can't upload anything on my arduino UNO R2. I'm still able to upload sketches using an USBtiny, but no communication between the computer and the board when using the usb connection.
I got an "avrdude: stk500_getsync(): not in sync: resp=0x00" error when trying.
Although I followed the advices given here, I'm still stuck.

My board doesn't pass the loopback test.

The other problem is, I can't seem to be able to get the atmega 8u2 in DFU mode. It does nothing when I try to connect reset and GND from the pin on its side.
Well, to be honest, I think it did something the first time. I had a new device in the device manager (I'm using Win 7 64 bits here).
But the only driver accepted was the arduino one for the Uno board. It didn't accept the flip driver...

Any hints on what should I do now?

Thanks!

I got the reflash to work, but unfortunately it didn't fix the problem. It still fails the loopback test, and uploading a sketch won't work either, do you have some more things I could try or should I write this one off?

@gromain
If it doesn't take you driver, you could try doing it manually with hdwwiz.exe (in the start menu, search for hdwwiz and hit enter). Let me know how you get on.

I got the reflash to work, but unfortunately it didn't fix the problem. It still fails the loopback test, and uploading a sketch won't work either, do you have some more things I could try or should I write this one off?

Even if the Loopback failed, since you were able to reflash the chip with no errors, the Atmega16u2 should be fine. Now, the focus can turn to the bootloader, but we do need an ISP (Second Arduino or AVRISP).

For grins, try this:

Hold down the reset button and unplug the USB cable.
Select a sketch and upload to the Uno (Reset still held down).
When any activity occurs on the Rx/Tx LEDs, release the button.

Thanks for the quick answers!

I tried the hdwwiz method, but when I changed the driver, it still didn't want to take the driver (I got something about the driver not being compatible with my device). I'm running Win7 in 64 bits, does this could be the reason? (i.e. no atmel dfu driver for win7 64bits?)

For your informations, the informations about the driver in the device manager are as follow:

Driver Provider: http://www.arduino.cc
Driver Date: 15/11/2007
Driver Version: 5.1.2600.0
Digital Signer: Not digitally signed

And the setting for the port are those:

Bits per second: 115200
Data bits: 8
Parity: None
Stop bits: 1
Flow control: None

No luck apparently!

@gromain: Have you tried the Arduino IDE Enhanced?

http://arduino.cc/forum/index.php/topic,118440.0.html

gromain:
I'm running Win7 in 64 bits, does this could be the reason? (i.e. no atmel dfu driver for win7 64bits?)

No it shouldn't be a problem, because I'm also running win7 64bit and it works for me. I'm no expert in these things as you can see, so I'm afraid I can't help you out any further

Yep! I just found out about it yesterday, and tried it right away! Nice improvement, but still no luck!

I was wondering that maybe I could use a usbtiny to reprogram the atmega 8u2... Would that be possible?

Yup. Unless you like hugh paths, copy C:\Users\spcomputing\Desktop\arduino-1.0.1\hardware\arduino\firmwares\UNO-dfu_and_usbserial_combined.hex to C:\Users\spcomputing\Desktop\arduino-1.0.1\hardware\tools\avr\bin.

Hook the USBTiny to the 3x2 header behind the USB port with the red side of the ribbon towards pin 1/2 (furthest from the USB port).

Open a command prompt in C:\Users\spcomputing\Desktop\arduino-1.0.1\hardware\tools\avr\bin.

Type:

avrdude -p at90usb82 -F -P usb -c usbtiny -U flash:w:UNO-dfu_and_usbserial_combined.hex -U lfuse:w:0xFF:m -U hfuse:w:0xD9:m -U efuse:w:0xF4:m -U lock:w:0x0F:m

Hi!

Thanks for the help!

I tried your hint, but it seems there's some trouble with the chip itself...
Here is the error message I have when trying your command:

avrdude: initialization failed, rc=-1
avrdude: AVR device initialized and ready to accept instructions
avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
avrdude: Expected signature for AT90USB82 is 1E 93 82
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.

avrdude done.  Thank you.

Device signature = 0x000000 ? That doesn't seem right, right?
Should I try with -D ?

No, it is just saying that there is no "basic communication" with the chip. Before any flashing, the USBtiny or any ISP through AVRDUDE does a chip check. The 0x000000 means no reply. Does the Uno board power up when you connect the USBtiny? Try this to test the USBtiny. Switch the ISP header to the '328 and send:

avrdude -p m328p -P usb -c usbtiny -V

It will not do anything other than try to talk to the chip.

Just wanted some clarification.

For direct programming with USBTiny via ISP headers for the USB 8U2 or 16U2 you would use;

avrdude -p ATmega8U2 ...
or
avrdude -p ATmega16U2 ...

The other type for -p at90usb82 would be for DFU programming mode via USB cable?

The other type for -p at90usb82 would be for DFU programming mode via USB cable?

No, the USB access to the Atmega8/16u2 through FLIP does not use AVRDUDE, so the part (-p at90usb82) used is actually ATMEGA8U2 or ATMEGA16U2 in the FLIP software. If you are to program the DFU through the header with a USBtiny, then AVRDUDE is used with the Arduino IDE. I am using the README.TXT included with the Arduino IDE for the Atmega8u2:

\arduino-1.0.1\hardware\arduino\firmwares\readme.txt

rduino Uno and Mega 2560 Firmwares for the ATmega8U2

This directory contains the firmwares used on the ATmega8U2 on the Arduino
Uno and Arduino Mega 2560. The arduino-usbdfu directory contains the DFU
bootloader on the 8U2; the arduino-usbserial directory contains the actual
usb to serial firmware. Both should be compiled against LUFA 100807. The
two .hex files in this directory combine the dfu and serial firmwares into
a single file to burn onto the 8U2.

To burn (Uno):
avrdude -p at90usb82 -F -P usb -c avrispmkii -U flash:w:UNO-dfu_and_usbserial_combined.hex -U lfuse:w:0xFF:m -U hfuse:w:0xD9:m -U efuse:w:0xF4:m -U lock:w:0x0F:m

To burn (Mega 2560):
avrdude -p at90usb82 -F -P usb -c avrispmkii -U flash:w:MEGA-dfu_and_usbserial_combined.hex -U lfuse:w:0xFF:m -U hfuse:w:0xD9:m -U efuse:w:0xF4:m -U lock:w:0x0F:m

Note on USB Vendor IDs (VID) and Product IDs (PID): The arduino-usbdfu
project uses Atmel's VID and MCU-specific PIDs to maintain compatibility
with their FLIP software. The source code to the arduino-usbserial
project includes Atmel's VID and a PID donated by them to LUFA. This
PID is used in LUFA's USBtoSerial project, which forms the basis for
arduino-usbserial. According to the LUFA documentation, this VID/PID
combination is:

"For use in testing of LUFA powered devices during development only,
by non-commercial entities. All devices must accept collisions on this
VID/PID range (from other in-development LUFA devices) to be resolved
by using a unique release number in the Device Descriptor. No devices
using this VID/PID combination may be released to the general public."

The production version of the arduino-usbserial firmware uses the
Arduino VID. This is only for use with official Arduino hardware and
should not be used on other products.

While I have not tested the "actual" part of -p m16u2 or -p m8u2 the -p at90usb82 works well as documented. I also tested -p at90usb162 with the same success. I am not sure if -p ATmega8U2 or -p ATmega16U2 will respond with much success since they are only descriptors:

avrdude.conf

#------------------------------------------------------------

ATmega16U2

#------------------------------------------------------------

Changes against ATmega32U2 (beside IDs)

memory "flash"

size = 16384;

num_pages = 128;

memory "eeprom"

size = 512;

num_pages = 128;

part
id = "m16u2";
desc = "ATmega16U2";
has_jtag = no;
has_debugwire = yes;
signature = 0x1e 0x94 0x89;
chip_erase_delay = 9000;
reset = io;

and

#------------------------------------------------------------

ATmega8U2

#------------------------------------------------------------

Changes against ATmega16U2 (beside IDs)

memory "flash"

size = 8192;

page_size = 64;

blocksize = 64;

part
id = "m8u2";
desc = "ATmega8U2";
has_jtag = no;
has_debugwire = yes;
signature = 0x1e 0x93 0x89;
chip_erase_delay = 9000;
reset = io;

Thanks for all the answers!

As for the USBtiny, I know it works well, I've used it to program the 328 with blink (to test the board, and it works well), and to put the bootloader back.

And the chip does power up when I connect the USBTiny. Should I try to connect the usb at the same time (to provide another power source for the chip while programming it)?

Should I try to connect the usb at the same time (to provide another power source for the chip while programming it)?

No, only one power source at a time. You can turn the "Target Power" OFF (JP3 jumper pulled) on the USBtiny and power it from the USB, but I suspect the same results.

Do you get any activity on the Rx/Tx LEDs?

Another longshot is turning the clock down on the USBtinyISP with a -B 32 in the command line.

avrdude -p at90usb82 -B 32 -P usb -c usbtiny -U flash:w:UNO-dfu_and_usbserial_combined.hex -U lfuse:w:0xFF:m -U hfuse:w:0xD9:m -U efuse:w:0xF4:m -U lock:w:0x0F:m

Sorry, I don't mean to get too off the subject. Just trying to make some sense of things.

While I have not tested the "actual" part of -p m16u2 or -p m8u2 the -p at90usb82 works well as documented. I also tested -p at90usb162 with the same success. I am not sure if -p ATmega8U2 or -p ATmega16U2 will respond with much success since they are only descriptors:

I think the arduino-1.0.1\hardware\arduino\firmwares\arduino-usbserial\makefile explains it.

MCU name(s)

Since the ATMEGA8U2 part is not directly supported by the current

versions of either avrdude or dfu-programmer, we specify a dummy

part; AT90USB82 which is close enough in memory size and organization

MCU = atmega8u2
MCU_AVRDUDE = at90usb82
MCU_DFU = at90usb82

# MCU name(s)
#    Since the ATMEGA8U2 part is not directly supported by the current
#   versions of either avrdude or dfu-programmer, we specify a dummy
#   part; AT90USB82 which is close enough in memory size and organization

Nice find hiduino! I haven't explored all the Arduino IDE files as of yet :wink:

Hi everyone,

It seems nothing will do... Still got the same errors. The chip may be dead!

Well, too bad, but I'll use it for a reflow oven controller, so it won't need the usb communication!
At least, I'm reusing it!

Thanks again to everyone for the help!

Cheers,

Gromain

I finally got my UNO to take an upload.

I tried everything I could to get an upload and spent hours trying to fix it, re-installing USB drivers, etc.

I had installed some USB hubs on my Win7 computer and they worked all right with other Arduino boards.

Then I decided to plug the cable directly into the standard USB port on the computer and that fixed the problem.

Hope this helps someone.

Hi,I had exactly same problem and just replaced Atmega328 with bootloader.I think there is no issue with drivers or etc.
Fuses or bootloader may be your problem.Buy new