Hello,
I was a happy USBasp user, until I switched to Windows 11 just a few days ago.
I'm using an USB 2.0 port for the USBAsp, I installed the driver using Zadig, just as I did under Windows 10.
In the device manager the USBasp is listed without any error:
Although only COM1 can be selected in the IDE, but I can't remember whether USBasp should have another COM port.
If I try to Upload Using Programmer, I get the following error:
avrdude: Warning: cannot query manufacturer for device: No such file or directory
avrdude: Warning: cannot query product for device: No such file or directory
avrdude: error: could not find USB device with vid=0x16c0 pid=0x5dc vendor='www.fischl.de' product='USBasp'
Failed programming: uploading error: exit status 1
Avrdude command line is also not working:
Could anyone help me get this working?
Thanks in advance.
Hi @amazed. Try using Zadig to install the "libusbK" driver for the USBasp instead of the "libusb-win32" driver you are using currently.
Hopefully the "Upload Using Programmer" operation will work after you do that.
It does not. This is a pure USB device that doesn't use serial ports at all. So it is normal and expected that you won't see a serial port in Arduino IDE's Tools > Port menu, and it doesn't matter which port (if any) you have selected at the time you perform the "Upload Using Programmer" operation.
You must specify the location of the avrdude.conf file via a -C flag in the command line:
https://avrdudes.github.io/avrdude/8.0/avrdude_4.html#index-_002dc-wildcard_002fflags
If you enable verbose upload output in the Arduino IDE preferences, then perform an "Upload Using Programmer" operation, you can use the avrdude command that is shown in Arduino IDE's Output" panel as the reference for the correct way to configure an AVRDUDE command to run directly from the command line.
Hi @ptillisch.
Thank you, this did the trick!
However the upload is much slower, than it used to be. Any tips on that?
After my initial confusion, I thought about the error message a bit and it occurred to me that the avrdude.conf file's directory also needs to be added to the PATH part of the environment (system) variables. The command line also works now.
Is this when you are using Arduino IDE, or the command line, or both?
I ask because I see you are using the -B flag in your command line to configure the bit clock period:
https://avrdudes.github.io/avrdude/8.0/avrdude_4.html#index-_002db-baudrate
This will affect the flashing duration. The "USBasp" programmer definition used by Arduino IDE when you have one of the "Arduino AVR Boards" platform's boards selected from Arduino IDE's Tools > Board menu doesn't configure a bit clock period, so it uses the default period set by the USBasp firmware (the unofficial variants of which have an auto-configuration capability).
This is when I'm using the IDE for upload.
I'm not intended to upload via command line.
Yeah, that is just my first, "check this thing if it's working" command after a custom board arrives (328P on 1MHz based on internal oscillator).
When you upload a sketch using Arduino IDE, it actually performs two distinct operations:
- Compile the sketch.
- Flash the compiled binary to the target.
If you watch the notifications that are shown at the bottom right corner of the Arduino IDE window, you will see a "Compiling sketch.." notification that changes to "Done compiling." when the compilation phase is completed, then an "Uploading..." notification that changes to "Done uploading." when the flashing phase is completed.
Is the unexpected duration in the flashing phase specifically, or in the compilation phase, or in both of them?
The reason I moved to Win11 in the first place was a PC upgrade. The compilation time couldn't be any better. 
But I don't have any numerical data how the flashing duration changed (or not) compared to Win10 (using the libusb-win32 driver). It may even be that this is just a subjective feeling, compared to the accelerated compilation time.
One thing you might check is if you have the Verify code after upload preference enabled. If enabled, the flash memory is read after the flashing phase so that it can be compared against the binary file. This is a measure to ensure that no corruption occurred, but it does take some extra time. So it could be that previously you had that preference disabled and you now have it enabled.
It is fairly rare to see this verification fail, so you might decide that it isn't necessary. When we do see it occur, it is often associated with cheap boards purchased from sketchy sellers, or perhaps with boards that have been subjected to electrical conditions outside their rated maximums.
