Vista x64: AVR Studio vs USB AVR Programmer

No matter what I do, I cannot get both AVR Studio and the drivers for the USB AVR Programmer working simultaneously on Vista Home Premium 64bit.

First I followed the directions on the USB AVR Programmer page to install the drivers.
I plugged in the Programmer, and got a “USB Device not recognized” warning, and the device was listed as “Unknown Device” in the Device Manager.
I did a system restore.

Apparently, driver signature enforcement has to be turned off for these drivers to install. I think the instructions should be altered to reflect this. Anyway, I rebooted while hitting F8 and disabled driver signature enforcement. This time the drivers installed properly. The Pololu device and the two USB->COM devices appeared in the Device Manager.
I installed WinAVR without incident.
When I installed AVR Studio, the device disconnected sound played. After finishing, the USB AVR Programmer no longer worked. I would once again receive "USB device not recognized. I tried reinstalling the drivers, but this did not work.
I did a system restore.

I repeated everything above, except I deselected the Install/Update USB drivers option during AVR Studio installation. This did not fix the issue.
I did a system restore.

This time around, I disabled driver signature enforcement, and I installed WinAVR and AVR Studio first (with install/update usb drivers selected). THEN I installed the USB AVR Programmer as per instructions. It didn’t work. I got the same “USB device not recognized” message and “Unknown Device” in device manager.
I did a system restore.

I repeated the above, this time deselecting the install/update usb drivers option during AVR Studio installation. Then I installed the USB AVR Programmer as per instructions. Again, it didn’t work. I got the “USB device not recognized” message.

Hello, I am using Windows Vista Home Premium 64-bit, Service Pack 1, with AVR Studio 4.16, and the USB AVR Programmer works fine on my computer, so hopefully we can figure out what’s going wrong for you.

First of all, we have two different programmer products so I’d like to make sure we both know which one you are using.

If you are using the Pololu USB AVR Programmer, you should follow these directions.

If you are using our older Orangutan USB Programmer, you should follow these directions.

This was the first thing that went wrong. Even if the drivers have not been installed at all, you should be able to plug in the programmer and see these three entries in the Device Manager under “Other Devices”:

Pololu USB AVR Programmer
Pololu USB AVR Programmer Programming Port
Pololu USB AVR Programmer TTL Serial Port

If you select “View -> Devices by Connection”, then you should be able to find a device called “USB Composite Device” which is a parent of all of those entries. It will be under something like “ACPI x64-based PC -> Microsoft ACPI-Compliant System -> PCI bus -> Standard OpenHCD USB Host Controller -> USB Root Hub”.

Before installing any drivers, could you please try just plugging in the programmer, viewing your devices by connection, and telling me all the entries that you see that are related to the programmer? Could you please tell me the Hardware IDs for each device by right-clicking and selecting “Properties -> Details -> Hardware IDs”?

I expect it to be something like this:
USB Composite Device [USB\VID_1FFB&PID_0081&REV_0001, USB\VID_1FFB&PID_0081]
Pololu USB AVR Programmer [USB\VID_1FFB&PID_0081&REV_0001&MI_04, USB\VID_1FFB&PID_0081&MI_04]
Pololu USB AVR Programmer Programming Port [USB\VID_1FFB&PID_0081&REV_0001&MI_00, USB\VID_1FFB&PID_0081&MI_00]
Pololu USB AVR Programmer TTL Serial Port [USB\VID_1FFB&PID_0081&REV_0001&MI_02, USB\VID_1FFB&PID_0081&MI_02]

Also, if you see any error messages in the “Device Status” field in the “General” tab for for the “Properties” window of any of these devices, please let me know.

It’s strange that turning off Driver Signature enforcement had an effect on your driver installation. Turning that off should only necessary if you are using the older Orangutan USB Programmer. With the newer programmer, you don’t need to do that because the binary drivers we are using are all provided by Microsoft (usbccgp.sys, usbser.sys, winusb.sys) and all we provide are the INF files (and some co-installer DLLs that were created by Microsoft).

That’s good that you are using System Restore to get your system back to a known good point. You should also try right-clicking on the malfunctioning device in the Device Manager and selecting “Uninstall”. Check the box for deleting the driver software too. Then unplug the device and plug it back it in. If you do this enough times, Windows will forget everything it knows about the device, which is good if there were any bad drivers installed on your system.

Thanks for the help.

I was following these instructions, and that is also where I downloaded the drivers. The back of the programmer PCB says PGM03A. It was part of the SV-328 + programmer bundle deal. Both the bundle’s product description and the packaging call it the USB AVR Programmer.

As you asked, I tried plugging it in without installing any drivers. First i got this:

Shot at 2009-08-31

In the Device Manager, all I got was a single item called “Unknown Device” under one of the USB root hubs. “Properties -> Details -> Hardware IDs” shows “USB\UNKNOWN” and nothing else. “Device Status” says “No drivers are installed for this device.”

This is strange. The only time I would expect this behavior from is if there was some bug or hardware problem in the programmer that was preventing it from reporting its Product ID and Vendor ID to the computer. One of the very first things that the computer does when it detects a new USB device is to ask it for its device descriptor, which contains those two numbers, and it uses that information to create the hardware ID.

What version of AVR Studio are you installing? This morning I installed version 4.17.666 while a USB AVR Programmer was plugged in, and it hasn’t caused any problems with the programmer (I’m using Vista 64-bit Home Premium just like you).

When it shows up as an Unknown Device, what are the LEDs on the programmer doing? I would expect the green LED to blink slowly (with a period of 1.4s) and the other LEDs should be off. This indicates the the programmer has not received the SET_CONFIGURATION request from the host; this request is a sign that the top-level driver (usbccgp.sys) is working properly and clearly it is not in your case.

The one time when it looked like you successfully installed the programmer’s drivers, I’m wondering whether they really were successfully installed. Can you try opening the programmer’s TTL Port in a simple terminal program such as Br@y Terminal. Just being able to open the serial port is a good sign that the drivers are working properly, but it would be even better if you could temporarily connect a wire between the programmer’s RX and TX lines, and type a character in the terminal program, and see if you see the same character echoed back to you. Also, please try running the programmer’s configuration utility: if it works then that means the drivers are working, and if it gives an interesting error message then that might help us determine the problem.

So if it turns out that the drivers actually were successfully installed in the past, then it certainly appears that AVR Studio is interfering the programmer’s drivers at some low level. Are there any other USB devices plugged in to your computer that might cause the problem, perhaps some other type of AVR programmer? (Well, from your screenshot it looks like you just have a mouse.) If not, then the only other thing I can think of is that AVR Studio installed some kind of filter driver. For the Host Controller, the USB Root Hub, and the Unknown Device in your screen shot, could you right click on each, select Properties, select Driver tab, click Driver Details, and tell me what items you see in the “Driver Files” list? For the Unknown Device, this list should probably be empty (I’m not sure though). For the USB Root Hub on my computer, I see usbd.sys and usbhub.sys. For the Host Controller on my computer, I see usbhub.sys, usbohci.sys, usbport.sys, and hcrstco.dll.

Anyway, if we can’t figure out what’s wrong with your AVR Studio, then you can always just use some standard editor to edit your files (I like Microsoft Visual Studio C++), use a make and a Makefile to compile your programs, and program the AVR using avrdude which comes with WinAVR. Just type “avrdude” at a Command Prompt to learn about it.


I was installing AVR Studio 4.17.666.

When Unknown Device shows up, the green LED flashes a single time. That is all.

The one time I had it working, I was able to open the configuration utility and sloscope without errors.

For the ICH10 host controller:

For the Root Hub:

For the Unknown Device: nothing.

I’m rather new to AVR’s, C/C++ and such, so I was planning to follow the instructions and documentation provided by pololu as closely as possible. For example, the SV-328 users guide has a download for a simple LED blinking program to test that the software is working properly, and these are said to be compressed AVR Studio project files. Can I open these in other editors? Heck, I’m used to simple stuff like Basic Stamps and Pic Axe controllers, so I’m not even sure whether “editor” means what I think it means in the world of C and AVR’s.

I’ll try installing everything on a netbook running XP tomorrow and let you know how that goes. If that doesn’t work I’ll try Br@y Terminal. If it does work, well, I’d still prefer to do my programming on a nice 24" screen rather than a Mini 10.

By the way, I did a search for usbccgp.sys, usbser.sys, and winusb.sys. Either Window’s doesn’t search system folders, or they aren’t there.

Actually, that LED behavior makes sense too. If the computer doesn’t get a good descriptor from the device, it will often just shut down the port (either by not sending signals or by not sending power). That would make the green LED go off.

Unless something is very messed up, that means that your usbccgp.sys and winusb.sys were working, and it means that the programmer hardware and cable itself were working.

Okay, nothing unusual there.

Yes, the user’s guide says that the blinking LED demo for the 328 is a “compressed AVR Studio project” but that’s not strictly true. Since you’re not sure what “editor” means, I’ll just go through and review all the files in that package, with the goal that you will understand them well enough that you won’t need to use AVR Studio:

  • BlinkLED.c: This .c file contains the source code of the program, written in the C language. This is where you define functions and variables. The function called main() is the one that gets run first when the AVR starts up. Your program can have multiple .c files, but should only have one main() function. You can use any plain-text editor you want to edit these files, such as AVR Studio or Notepad or Emacs.
  • BlinkLED.aps: This .aps file is an AVR Studio Project file that tells AVR Studio which files are in your project (e.g. BlinkLED.c), what processor to compile the project for, and any other compilation options that AVR Studio might need. This, along with the source files, are all you need to compile your program in AVR Studio. You can open .aps files up in Notepad and take a peek and what’s inside it.
  • This .aws file is (I think) called an AVR Studio Work Space. It contains information like which files you were looking at, and the positions of the windows from the last time you closed AVR Studio. This file is not important and can be deleted.
  • default/Makefile: A Makefile is a file that contains rules to create files from other files. In this case, it contains the commands needed to compile your program from its source files. If you open a Command Prompt and go to that directory and type “make”, your program will be compiled. This is a good way to compile a program without using AVR Studio.
  • The rest of the files in the “default” directory (.eep, .elf, .hex, .o, and dep/) are output files generated during compilation. The .hex file is in the Intel Hex file format and it contains all the bytes of your program that should be written to the flash (program memory) on the AVR. You can write the hex file to flash using our programmer along with any working programming software such as avrdude. This is a good way to load the program without using AVR Studio.

Though there are two different ways of compiling the BlinkLED demo (AVR Studio and make), they both are powered by two command-line programs that come in WinAVR: avr-gcc and avr-objcopy. Whenever you compile your program, all you are doing is running avr-gcc and avr-objcopy with different arguments. You can see what arguments AVR Studio uses if you select “Build -> Rebuild All” and look at the output in the “Build” pane at the bottom. You can see what arguments “make” uses because it outputs them on the screen as it runs. If you don’t like make or AVR Studio, you can always just take those commands and run them yourself at the Command Prompt, or paste them in to a simple .bat file and run that. The important thing is the commands themselves, not the program that is executes them.

Good luck with that. Never mind the Br@y Terminal test, I’m pretty sure it would succeed given that the configuraiton utility works.

They’re in C:\Windows\System32 if you want to find them.


Well… I still had yet to continue my efforts to get all this working when, this morning, I plugged a bulky flash drive into a directly adjacent USB port, and the programmer sprang to life. As best I can tell, the USB cord was not making proper contact with the pins in the socket. The pressure of the flash drive is the only thing keeping it working at the moment; if I remove it, the programmer disconnects.

I just installed WinAVR and AVR Studio. All is working as it should.

Anyway, I’m sorry for wasting your time on this, and I appreciate you taking the time to help.