B. Troubleshooting

In general, please report any bugs encountered via
https://github.com/avrdudes/avrdude/issues.

• 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 (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.

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

  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.

• Problem: Updating the flash ROM from terminal mode does not work with the JTAG ICEs.

  Solution: None at this time. Currently, the JTAG ICE code cannot write to the flash ROM one byte at a time.

• Problem: Page-mode programming the EEPROM (using the -U option) does not erase EEPROM cells before writing, and thus cannot overwrite any previous value != 0xff.

  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.

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

• Problem: Multiple USBasp or USBtinyISP programmers connected simultaneously are not found.

  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 dependent; 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)

• 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 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.

• 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:

  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

• 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 by this time (2010 Q1).

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

• Problem: when programming with an AVRISPmkII or STK600, AVRDUDE hangs when programming files of a certain size (e.g. 246 bytes). Other (larger or smaller) sizes work though.

  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

• 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 March 11, 2023 using texi2html 1.82.