In general, please report any bugs encountered via
http://savannah.nongnu.org/bugs/?group=avrdude.
avrdude: serial_open(): can't set attributes for device "com1",
Solution: This problem seems to appear with certain versions of Cygwin. Specifying
"/dev/com1" instead of "com1" should help.
Solution (short): setserial port low_latency
Solution (long): There are two problems here. First, the system may wait some time before it passes data from the serial port to the program. Under Linux the following command works around this (you may need root privileges for this).
setserial port low_latency
Secondly, the serial interface chip may delay the interrupt for some time.
This behaviour can be changed by setting the FIFO-threshold to one. Under Linux this
can only be done by changing the kernel source in drivers/char/serial.c.
Search the file for UART_FCR_TRIGGER_8 and replace it with UART_FCR_TRIGGER_1. Note that overall performance might suffer if there
is high throughput on serial lines. Also note that you are modifying the kernel at
your own risk.
Solutions: The reasons for this are the same as above. If you know how to work around this on your OS, please let us know.
Solution: None at this time. Currently, the JTAG ICE code cannot write to the flash ROM one byte at a time.
Solution: None. This is an inherent feature of the way JTAG EEPROM programming works, and is documented that way in the Atmel AVR datasheets. In order to successfully program the EEPROM that way, a prior chip erase (with the EESAVE fuse unprogrammed) is required. This also applies to the STK500 and STK600 in high-voltage programming mode.
Solution: If the DWEN (debugWire enable) fuse is activated, the /RESET pin is not functional anymore, so normal ISP communication cannot be established. There are two options to deactivate that fuse again: high-voltage programming, or getting the JTAG ICE mkII talk debugWire, and prepare the target AVR to accept normal ISP communication again.
The first option requires a programmer that is capable of high-voltage programming (either serial or parallel, depending on the AVR device), for example the STK500. In high-voltage programming mode, the /RESET pin is activated initially using a 12 V pulse (thus the name high voltage), so the target AVR can subsequently be reprogrammed, and the DWEN fuse can be cleared. Typically, this operation cannot be performed while the AVR is located in the target circuit though.
The second option requires a JTAG ICE mkII that can talk the debugWire protocol. The ICE needs to be connected to the target using the JTAG-to-ISP adapter, so the JTAG ICE mkII can be used as a debugWire initiator as well as an ISP programmer. AVRDUDE will then be activated using the jtag2isp programmer type. The initial ISP communication attempt will fail, but AVRDUDE then tries to initiate a debugWire reset. When successful, this will leave the target AVR in a state where it can accept standard ISP communication. The ICE is then signed off (which will make it signing off from the USB as well), so AVRDUDE has to be called again afterwards. This time, standard ISP communication can work, so the DWEN fuse can be cleared.
The pin mapping for the JTAG-to-ISP adapter is:
| JTAG pin | ISP pin |
| 1 | 3 |
| 2 | 6 |
| 3 | 1 |
| 4 | 2 |
| 6 | 5 |
| 9 | 4 |
Solution: The USBtinyISP code supports distinguishing multiple programmers based on their bus:device connection tuple that describes their place in the USB hierarchy on a specific host. This tuple can be added to the -P usb option, similar to adding a serial number on other USB-based programmers.
The actual naming convention for the bus and device names is operating-system dependant; AVRDUDE will print out what it found on the bus when running it with (at least) one -v option. By specifying a string that cannot match any existing device (for example, -P usb:xxx), the scan will list all possible candidate devices found on the bus.
Examples:
avrdude -c usbtiny -p atmega8 -P usb:003:025 (Linux) avrdude -c usbtiny -p atmega8 -P usb:/dev/usb:/dev/ugen1.3 (FreeBSD 8+) avrdude -c usbtiny -p atmega8 \ -P usb:bus-0:\\.\libusb0-0001--0x1781-0x0c9f (Windows) |
Solution: debugWire mode imposes several limitations.
The debugWire protocol is Atmel’s proprietary one-wire (plus ground) protocol to allow an in-circuit emulation of the smaller AVR devices, using the /RESET line. DebugWire mode is initiated by activating the DWEN fuse, and then power-cycling the target. While this mode is mainly intended for debugging/emulation, it also offers limited programming capabilities. Effectively, the only memory areas that can be read or programmed in this mode are flash ROM and EEPROM. It is also possible to read out the signature. All other memory areas cannot be accessed. There is no chip erase functionality in debugWire mode; instead, while reprogramming the flash ROM, each flash ROM page is erased right before updating it. This is done transparently by the JTAG ICE mkII (or AVR Dragon). The only way back from debugWire mode is to initiate a special sequence of commands to the JTAG ICE mkII (or AVR Dragon), so the debugWire mode will be temporarily disabled, and the target can be accessed using normal ISP programming. This sequence is automatically initiated by using the JTAG ICE mkII or AVR Dragon in ISP mode, when they detect that ISP mode cannot be entered.
Solution: Use the following pin mapping:
| JTAGICE | Target | Squid cab- | PDI |
| mkII probe | pins | le colors | header |
| 1 (TCK) | Black | ||
| 2 (GND) | GND | White | 6 |
| 3 (TDO) | Grey | ||
| 4 (VTref) | VTref | Purple | 2 |
| 5 (TMS) | Blue | ||
| 6 (nSRST) | PDI_CLK | Green | 5 |
| 7 (N.C.) | Yellow | ||
| 8 (nTRST) | Orange | ||
| 9 (TDI) | PDI_DATA | Red | 1 |
| 10 (GND) | Brown |
Solution: Use the 6 pin ISP header on the Dragon and the following pin mapping:
| Dragon | Target |
| ISP Header | pins |
| 1 (MISO) | PDI_DATA |
| 2 (VCC) | VCC |
| 3 (SCK) | |
| 4 (MOSI) | |
| 5 (RESET) | PDI_CLK / RST |
| 6 (GND) | GND |
Solution: Use the following pin mapping:
| AVRISP | Target | ATtiny |
| connector | pins | pin # |
| 1 (MISO) | TPIDATA | 1 |
| 2 (VTref) | Vcc | 5 |
| 3 (SCK) | TPICLK | 3 |
| 4 (MOSI) | ||
| 5 (RESET) | /RESET | 6 |
| 6 (GND) | GND | 2 |
Solution: Since TPI has only 1 pin for bi-directional data transfer, both MISO and MOSI pins should be connected to the TPIDATA pin on the ATtiny device. However, a 1K resistor should be placed between the MOSI and TPIDATA. The MISO pin connects to TPIDATA directly. The SCK pin is connected to TPICLK.
In addition, the Vcc, /RESET and GND pins should be connected to their respective ports on the ATtiny device.
Solution: When connecting the FT232 directly to the pins of the target Atmel device,
the polarity of the pins defined in the programmer definition should be
inverted by prefixing a tilde. For example, the dasa programmer would
look like this when connected via a FT232R device (notice the tildes in
front of pins 7, 4, 3 and 8):
programmer id = "dasa_ftdi"; desc = "serial port banging, reset=rts sck=dtr mosi=txd miso=cts"; type = serbb; reset = ~7; sck = ~4; mosi = ~3; miso = ~8; ; |
Note that this uses the FT232 device as a normal serial port, not using the FTDI drivers in the special bitbang mode.
Solution: Mind the limited programming supply voltage range of these devices.
In-circuit programming through TPI is only guaranteed by the datasheet at Vcc = 5 V.
Solution: None by this time (2010 Q1).
It is said that the AVR Dragon can only program devices from the A4 Xmega sub-family.
Solution: This is a bug caused by an incorrect handling of zero-length packets (ZLPs) in some versions of the libusb 0.1 API wrapper that ships with libusb 1.x in certain Linux distributions. All Linux systems with kernel versions < 2.6.31 and libusb >= 1.0.0 < 1.0.3 are reported to be affected by this.
See also: http://www.libusb.org/ticket/6