AVRDUDE: Appendix B Troubleshooting

Appendix B Troubleshooting

AVRDUDE’s wiki https://github.com/avrdudes/avrdude/wiki is a great place to learn about installing AVRDUDE on various platforms and, generally, to learn a few tricks of the trade. In paticular, the FAQ and the known limitations of avrdude are worth reading.

Here a few examples for things that can go wrong and what to do:

Problem: I’m using a serial programmer under Windows and get the following error:

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.

Problem: I’m using Linux and my AVR910 programmer is really slow.

Solution: 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.

Problem: I’m not using Linux and my AVR910 programmer is really slow.

Solution: The reasons for this are the same as above. If you know how to work around this on your OS, please let us know.

Problem: Page-mode programming the EEPROM using the -U option does not erase EEPROM cells before writing, and thus cannot necessarily overwrite non-0xff values.

Solution: This is an inherent feature of how JTAG EEPROM programming works, and is documented as such in the datasheets. In order to successfully program the EEPROM, a prior chip erase with the EESAVE fuse unprogrammed is required. This also applies to the STK500 and STK600 in high-voltage programming mode.

The terminal, however, recognises that the programmer struggles to write to EEPROM. It then reads flash, EEPROM and, if present, bootrow contents, performs a chip erase and then writes these memories back. This happens when flushing the cache or leaving the terminal and takes some time. EESAVE needs to be unprogrammed for this.

Problem: How do I turn off the DWEN fuse?

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	ISP
	1	3
	2	6
	3	1
	4	2
	6	5
	9	4

Problem: Differentiate multiple USBtinyISP (or USBasp) programmers

Solution: The -c usbtiny programmer distinguishes multiple physical USBtinyISP devices based on their busdir:devicefile pairs that describe their place in the USB hierarchy on a specific host. This pair can be specified in the -P usb:busdir:devicefile option. The naming convention for the bus and device depends on the operating system. Examples for Linux, FreeBSD and Windows, respectively:

$ avrdude -c usbtiny -p atmega8 -P usb:003:025
$ avrdude -c usbtiny -p atmega8 -P usb:/dev/usb:/dev/ugen1.3
$ avrdude -c usbtiny -p atmega8 \
    -P 'usb:bus-0:\\?\usb#vid_16c0&pid_05dc#0001#{a5...ed}--WinUSB'

The Windows device name contains the backslash file separator, so the -P option will need appropriate quoting on the command line, eg, in bash with single quotes.

For USBasp the same -P usb:busdir:devicefile as with USBtiny selects the right device. Alternatively, USBasp can select the device via its serial number using -P usb:serialno.

Note that avrdude -v -P usb:xyz will print out suitable programmers on the bus assuming xyz does not match any device.

$ avrdude -v -Pusb:xyz -c usbasp -p m328p 2>&1 | grep ^Found
Found USBasp with busdir:devicefile = 001:008, serial_number = 0001
Found USBasp with busdir:devicefile = 001:009, serial_number = 1234

$ avrdude -qq -c USBasp -p atmega8 -P usb:34

Problem: I cannot do … when the target is in debugWIRE mode.

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 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, each flash 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.

Problem: I want to use my JTAG ICE mkII to program an Xmega device through PDI. The documentation tells me to use the XMEGA PDI adapter for JTAGICE mkII that is supposed to ship with the kit, yet I don’t have it.

Solution: Use the following pin mapping:

JTAG ICE	Target	Squid cable	PDI
mkII probe	pins	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

Problem: I want to use my AVR Dragon to program an Xmega device through PDI.

Solution: Use the 6 pin ISP header on the Dragon and the following pin mapping:

	Dragon	Target
	ISP Header	pins
	1 (SDI)	PDI_DATA
	2 (VCC)	VCC
	3 (SCK)
	4 (SDO)
	5 (RESET)	PDI_CLK / RST
	6 (GND)	GND

Problem: I want to use my AVRISP mkII to program an ATtiny4/5/9/10 device through TPI. How to connect the pins?

Solution: Use the following pin mapping:

AVRISP	Target	ATtiny
connector	pins	pin #
1 (SDI)	TPIDATA	1
2 (VTref)	Vcc	5
3 (SCK)	TPICLK	3
4 (SDO)
5 (RESET)	/RESET	6
6 (GND)	GND	2

Problem: I want to program an ATtiny4/5/9/10 device using a serial/parallel bitbang programmer. How to connect the pins?

Solution: Since TPI has only 1 pin for bi-directional data transfer, both SDI and SDO pins should be connected to the TPIDATA pin on the ATtiny device. However, a 1K resistor should be placed between the SDO and TPIDATA. The SDI 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.

Problem: How can I use a FTDI FT232R USB-to-Serial device for bitbang programming?

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 sdo=txd sdi=cts";
  type  = serbb;
  reset = ~7;
  sck   = ~4;
  sdo   = ~3;
  sdi   = ~8;
;

Note that this uses the FT232 device as a normal serial port, not using the FTDI drivers in the special bitbang mode.

Problem: My ATtiny4/5/9/10 reads out fine, but any attempt to program it (through TPI) fails. Instead, the memory retains the old contents.

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.

Problem: My ATxmega…A1/A2/A3 cannot be programmed through PDI with my AVR Dragon. Programming through a JTAG ICE mkII works though, as does programming through JTAG.

Solution: None (may be a firmware issue of the AVR Dragon).

It is said that the AVR Dragon can only program devices from the A4 Xmega sub-family.

Problem: after flashing a firmware that reduces the target’s clock speed (e.g. through the CLKPR register), further ISP connection attempts fail. Or a programmer cannot initialize communication with a brand new chip.

Solution: Even though ISP starts with pulling /RESET low, the target continues to run at the internal clock speed either as defined by the firmware running before or as set by the factory. Therefore, the ISP clock speed must be reduced appropriately (to less than 1/4 of the internal clock speed) using the -B option before the ISP initialization sequence will succeed.

As that slows down the entire subsequent ISP session, it might make sense to just issue a chip erase using the slow ISP clock (option -e), and then start a new session at higher speed. Option -D might be used there, to prevent another unneeded erase cycle.

This document was generated on July 11, 2026 using texi2html 5.0.