5.6. Troubleshooting AVR programming issues
This section helps solve problems you might have using the Pololu USB AVR Programmer v2.x to program AVRs.
If the programmer blinks its red LED and resets when you plug it into to the AVR:
If you are using Pololu USB AVR Programmer v2, and the programmer’s regulator mode is set to Auto or 3.3 V, and you plug it in to a device running at 5 V with a strong pull-up (less than 10kΩ) on its reset line, the programmer could experience a brown-out reset. After all the pins are connected, the programmer will indicate the brown-out by blinking its red LED four times, and then it will resume normal operation. Any programs using the programmer’s COM ports or its native USB interface might need to be restarted. You can avoid this by setting the regulator mode to 5 V, which can be done by running
pavr2cmd --regulator-mode 5v or using the Pololu USB AVR Programmer v2 Configuration Utility. The Pololu USB AVR Programmer v2.1 does not have this problem.
You could also experience a brown-out reset when connecting to an AVR if you have enabled the VCC output feature and the capacitance on the target AVR board’s VCC line is too high. For more information, see Section 8.
If a motor on your Baby Orangutan or 3pi Robot runs briefly:
If you plug a Pololu USB AVR Programmer v2 into a Baby Orangutan or 3pi Robot, motor 2 might run as you are plugging it in. After all the pins are connected, the motor will stop running. You can avoid this by adding
set_motors(0, 0); to the beginning of your program (e.g. the first line of
setup) to ensure that the motor PWM pins are driven low. The Pololu USB AVR Programmer v2.1 has improved circuitry for measuring the target’s logic voltage, which limits the duty cycle of this effect to about 0.2%, so the motor won’t move (but it might make a 25 Hz clicking sound).
If the computer fails to connect to the programmer:
- Make sure that your software is configured to connect to the programmer’s programming port, and not some other serial port on your computer. You can find the name of this port by looking in the upper left corner of the Pololu USB AVR Programmer v2 Configuration Utility software, or by following the instructions in Section 4.5.
- If you are using 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 programmer’s programming port. If there are multiple STK500 entries, right click on them and select “Remove” to remove the extra entries.
- If you are in Windows, make sure you have installed the drivers the programmer needs to operate. Section 4.1 describes how to install the drivers in Windows.
- Make sure your programmer is connected to your computer via a USB A to micro-B cable.
- Try closing all programs using the programmer, unplug the programmer from everything, and then plug it back into USB.
- Try using a different USB cable and a different USB port. Make sure your cable is not a charging-only cable.
- Is the programmer’s green USB status LED on? This is the LED next to the USB 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 “Universal Serial Bus devices” should be “Pololu USB AVR Programmer v2.1” (or v2), and under “Ports (COM & LPT)” should be “Pololu USB AVR Programmer v2.1 Programming Port” and “Pololu USB AVR Programmer v2.1 TTL Serial Port” (or v2) and there should be no error symbols on the icons representing these devices.
- On Windows, 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 Device Programming dialogs in all of them. When the Device Programming dialog is open and the Apply button at the top is grayed out, that instance of Atmel Studio has an open connection to your programmer’s programming port.
- See Section 4.1 for some tips on USB troubleshooting for Windows.
- See Section 4.2 for some tips on USB troubleshooting for Linux.
- See Section 4.3 for some tips on USB troubleshooting for macOS.
If the programmer has problems connecting to the target AVR:
- A common cause for this problem is an incorrect connection between your programmer and your target device. See Section 5.1 for information on how to properly connect an AVR to the programmer.
- The target AVR must be powered for programming to work. Please make sure that your target device has power and is turned on. You can get a reading of the AVR’s VCC voltage by running
pavr2cmd -sor looking in the Pololu USB AVR Programmer v2 Configuration Utility. If you are using Atmel Studio, you can get a reading of the 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.
- 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 114 kHz should work for most AVRs. Try setting the ISP frequency to 114 kHz using the programmer’s configuration utility, or by supplying the
-B 5option to AVRDUDE. You can also set the frequency using the Device Programming dialog in Atmel Studio, in the “Interface settings” section. If you are programming in Atmel Studio with F5, go to the “Tool” section of your project’s properties and set the frequency to 115.2 kHz by dragging the slider.
- If the red error LED is on solid after a programming attempt, then run the programmer’s configuration utility or run
pavr2cmd -sto 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 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 you are programming by pressing F5 in Atmel Studio, try using the “Device Programming” dialog instead. You can find it in “Tools” menu.
- It is possible that the AVR’s SPIEN fuse has been set to 1, meaning that the ISP interface is disabled. This could potentially happen if you used the AVR’s debugWIRE interface to program it. The debugWIRE interface is a different interface that is not supported by the Pololu USB AVR Programmer v2.x. To fix this problem, you should use the debugWIRE interface to set the SPIEN fuse to 0.
If the verification step fails for flash programming:
- Check the lock bits on your AVR to make sure you do not have any type of code protection or memory lock enabled. Since those settings would prevent the programmer from reading from your AVR’s flash, they would cause verification to fail.
If the verification step fails for fuses or lock bits:
- Verification of fuses or lock bits in AVRDUDE can fail because unimplemented fuse bits are read as an arbitrary, constant value that might be different from the value you tried to program into them. Consult the datasheet of your AVR to find out which fuse bits are unimplemented and then change those bits in your AVRDUDE command to match what AVRDUDE is actually reading from the chip. Be very careful whenever you are changing fuses!
Still need help?
If none of the above troubleshooting suggestions solve your problem, please contact us for support.