next topic »

[Reply #30 on:]

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?

[Reply #31 on:]

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:

Code:

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

[Reply #32 on:]

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:

Code:

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 ?

[Reply #33 on:]

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:

Code:

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

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

[Reply #34 on:]

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?

[Reply #35 on:]

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;

[Reply #36 on:]

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)?

[Reply #37 on:]

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.

Code:

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

[Reply #38 on:]

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

[Reply #39 on:]

Code:

# 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

[Reply #40 on:]

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