8. Troubleshooting

This section helps solve problems you might have using the Pololu USB AVR programmer.

If the computer fails to connect to the programmer:

• If you are using AVR Studio 5 or Atmel Studio, make sure that your programmer has firmware version 1.07 or later. Using a firmware version prior to 1.06 will result in an error message in the Output tab that says “The signature of the attached tool is AVRISP_2, which is unexpected” and “Atmel.VsIde.AvrStudio.Services.TargetService.TCF.Internal.Services.Remote.ToolProxy+ToolContext”, and a dialog box that says either “Unable to connect to tool STK500” or “AVR Studio was unable to start your debug session”. See Section 9 for information about determining your firmware version and upgrading.
• If you are using Mac OS X 10.11 or later, make sure that your programmer has firmware version 1.08 or later. See Section 5.a for more information.
• If you are using AVR Studio 5 or Atmel Studio and programming with the F5 key does not work, then click View > Available Atmel Tools. This will open the “Available Tools” window. Make sure that there is one and only one STK500 in the list and make sure that the COM port number matches the COM port number of the Pololu USB AVR Programmer Programming Port, which is displayed in the Device Manager. If there are multiple STK500 entries, right click on them and select “Remove” to remove the extra entries.
• Make sure your programmer is connected to your computer via a USB A to mini-B cable. If the programmer was previously working and has since stopped, try closing all programs using the programmer (the configuration utility, the SLO-scope client, and the Atmel Studio Device Programming dialog), and cycle the power by unplugging it from your computer and then reconnecting it.
• If you are in Windows, make sure you have installed the drivers the programmer needs to operate. Section 3.a describes how to install the drivers in Windows.
• Is the programmer’s green USB status LED on? This is the LED next to the USB mini-B connector. If this LED is blinking slowly, then your drivers are not properly installed.
• If you are in Windows, can you see your programmer listed in the Device Manager? The Device Manager should show three devices: under “Pololu USB Devices” should be “Pololu USB AVR Programmer”, and under “Ports (COM & LPT)” should be “Pololu USB AVR Programmer Programming Port” and “Pololu USB AVR Programmer TTL Serial Port” and there should be no error symbols on the icons representing these devices.
• If you are in Linux, check that /dev/ttyACM0 and /dev/ttyACM1 exist. If they do not, see the section below.
• Your computer will only let one program at a time have a given COM port open. If you are connected to your programmer’s programming port using another program, such as a terminal or a second instance of Atmel Studio, you will not be able to connect to that same COM port with your programming software. Please make sure you do not have any terminal programs connected to your programmer’s programming port. If you have multiple versions of Atmel Studio running, make sure that you have closed the ISP programming dialogs in all of them. When the ISP dialog is open, that instance of AVR Studio has an open connection to your programmer’s programming port.
• If you are using AVR Studio 4, try connecting to your programmer’s specific COM port instead of selecting the “Auto” option, which attempts to locate the port automatically. Some versions of AVR Studio 4 fail to automatically detect programmers on virtual COMs port that are too high (e.g. above COM9). If your programming COM port is too high to select from the connection dialog box and AVR Studio 4 does not automatically detect the programmer, you will need to reassign the programming port to a lower virtual COM port. You can do this by opening the properties dialog of the “Pololu USB AVR Programming Port” (found in the “Ports (COM & LPT)” section of the Device Manager) and clicking the “Advanced…” button under the “Port Settings” tab.

If the programmer has problems connecting to the target AVR:

• The most common cause for this problem is an incorrect connection between your programmer and your target device. If the ISP pins are misaligned between the programmer and the target AVR, the two will not be able to communicate. Please make sure that the ISP pins as numbered in Section 1.a are correctly connected between your AVR and your programmer (i.e. 1 goes to 1, 2 goes to 2, etc.).
• The target AVR must be powered for programming to work. Please make sure that your target device has power and is turned on. If you are using AVR Studio 5 or Atmel Studio, you can get a reading of your AVR’s VCC voltage by clicking the “Read” button next to the Target Voltage box in the upper right corner of the Device Programming dialog.
• If the target AVR is running at a voltage lower than 5 V, you may need to decrease the minimum allowed target VDD setting using the configuration utility (Section 3.e). Please note that you might need to take additional special steps to safely program an AVR that is running off of a voltage below VUSB-0.5 V.
• Your programmer’s ISP frequency must be less than a quarter of your target AVR’s clock frequency, but frequencies that are too low can result in timeouts. The default frequency of 200 kHz should work for most AVRs. Try setting the ISP frequency to 200 kHz using the configuration utility (Section 3.e) or by supplying the -B 3 option to AVRDUDE.
• If the red error LED is on solid, then run the configuration utility (Section 3.e) to determine the cause of the error.
• There may be a problem with the target device. It is possible to kill a device with a static shock, by incorrectly connecting power, or by programming the fuses incorrectly. There could also be a short or cut trace somewhere on your target device. The ideal way to test for this is to try programming a different device with your USB AVR programmer, or try using a different programmer to program your target device. If this is not an option, try verifying that the target device is still functional and perform some continuity tests to check for shorts or disconnections on the ISP programming lines. Don’t forget to check the 6-pin ISP cable for shorts as well.

If /dev/ttyACM0 or /dev/ttyACM1 do not exist in Linux:

• Try closing all programs using the programmer, unplugging the programmer, and plugging it back in.
• If the programmer is connected, the lsusb command should output a line like this (the important thing is the 1ffb:0081):
Bus 002 Device 002: ID 1ffb:0081
• If the CDC ACM driver detected the programmer when it was plugged in, then the dmesg command should have some output like this:
[   26.378771] /build/buildd/linux-2.6.24/drivers/usb/class/cdc-acm.c: This
device cannot do calls on its own. It is no modem.
[   26.380858] cdc_acm 2-1:1.0: ttyACM0: USB ACM device
[   26.413512] /build/buildd/linux-2.6.24/drivers/usb/class/cdc-acm.c: This
device cannot do calls on its own. It is no modem.
[   26.413542] cdc_acm 2-1:1.2: ttyACM1: USB ACM device
[   26.421314] usbcore: registered new interface driver cdc_acm
[   26.421333] /build/buildd/linux-2.6.24/drivers/usb/class/cdc-acm.c: v0.25:USB
Abstract Control Model driver for USB modems and ISDN adapters
• If the CDC ACM driver is associated with both serial ports of the programmer, then the /dev/bus/usb/devices file (or /proc/bus/usb/devices) should have a group of lines like this (the important thing is that Driver=cdc_acm should appear in four places):
T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=ef(unk. ) Sub=02 Prot=01 MxPS= 8 #Cfgs=  1
P:  Vendor=1ffb ProdID=0081 Rev= 0.01
S:  Manufacturer=Pololu Corporation
S:  Product=Pololu USB AVR Programmer
S:  SerialNumber=00000005
C:* #Ifs= 5 Cfg#= 1 Atr=80 MxPwr=100mA
A:  FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=02 Prot=01
A:  FirstIf#= 2 IfCount= 2 Cls=02(comm.) Sub=02 Prot=01
I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=cdc_acm
E:  Ad=81(I) Atr=03(Int.) MxPS=  10 Ivl=1ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_acm
E:  Ad=02(O) Atr=02(Bulk) MxPS=   8 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=   8 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=cdc_acm
E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=1ms
I:* If#= 3 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_acm
E:  Ad=04(O) Atr=02(Bulk) MxPS=   8 Ivl=0ms
E:  Ad=84(I) Atr=02(Bulk) MxPS=   8 Ivl=0ms
I:* If#= 4 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
E:  Ad=85(I) Atr=03(Int.) MxPS=  22 Ivl=1ms
Try comparing the outputs on your system to the outputs above to determine what went wrong.