Troubleshooting

Device Not Recognized Errors

Here are some things to try if you're trying to get V-USB to work, but getting the dreaded "Device Not Recognized" error in Windows, or your V-USB project isn't communicating or enumerating with your host.

1.- Fuses - Especially making sure that your clock is set to the right clock source (AVR's default to their internal oscillator, which only works with the 12.8 MHz code), and also make sure that CKDIV8 is turned off (technically set to 1, since AVR fuses are set by assigning them to 0).

2.- Compiling with the correct speed for you circuit - The V-USB library supports a variety of different speeds. Fortunately, it won't compile (compiler warning) if you don't set the speed to an eligible speed, but make sure you change the F_CPU value in the makefile or the code or in AVR Studio to the same speed as the clock you're using.

3.- EMI - Electromagnetic interference is also a big problem for V-USB, depending on how you have things laid out. Make sure you have some decoupling capacitors (like 0.1uF or so) between your power and ground pins, as close to the pins as possible, and at all the power/ground pins. You might also have problem with cable shielding if you're using a cut-open USB cable; try connecting the metal braid that wraps around the wire to ground somewhere on your board.

The AVR seems to be especially sensitive to spikes on I/O ports which exceed the supply voltages. Long wires connected directly to I/O pins may be the source of such spikes. And a good candidate for long wires on I/O pins are the USB data lines D+ and D-. You can absorb parts of the spike energy with ca. 100 pF capacitors from the D+ and D- I/O pins to ground. But be careful: If the value is too high, it may cause signal distortions. If it's too low, the capacitor has no effect.

4.- Circuit board issues - Double check that your circuit matches the schematic. For instance, make sure your diodes are going the correct way, or that you have a pull-up resistor on the RESET pin - I've also had issues where if I have an unplugged ISP programmer attached to my board, it pulls the RESET line low enough to occasionally keep resetting the AVR, so try unplugging your programmer from your board, at least unhook any wires connected to the RESET pin. Also, the pull-up resistor on D- is 1.5K ohm in the USB specification. It can be higher, but it might not work - for instance, 10K resistors will work about half of the time, but then you don't know why half of your projects don't work.

Use low power dissipation zener diodes if 5V supply is being used for the controller. 0.5W 3.6V zener diodes can be used with 1.5k pull-up resistor. High power dissipation zener diodes may require trial-and-error tests to choose the right pull-up resistors.

5.- Try known code - Make sure a ready-made project already works for you, then start messing around with that code. I personally always use HID-Mouse.

6.- Interrupts and Timing - Make sure that you're not using interrupts higher than the interrupt you have set for VUSB. Also make sure you're not disabling interrupts for longer than a few milliseconds, or that you have more than 10ms between calls to usbPoll(). A common mistake is to have sections of floating-point calculations in a main loop which does call usbPoll(), however, keep in mind that floating-point math is EXTREMELY slow, it may be worthwhile to place usbPoll() before and after these calculations.

7.- Windows VID/PID issues - Windows caches VID/PID pairs, so if you've been using one device type (like an HID mouse) with one VID/PID pair, then you try and use the same pair with another device type, Windows might still expect a mouse and therefore reject your new device.

8.- Don't compile for 'P' series chips - There is an issue in the driver where some interrupt tables are named in a way that isn't compatible with chips that have a 'p' after their name - i.e. ATmega168p, ATmega3280. This is tricky, since the code will compile, but just won't work. However, the 'p' series chips are binary compatible with their non-'p' cousins, so if you're working with an ATmega168p, compile for a regular ATmega168. The ATmega328p has no non-p variant, but it's binary-compatible with the ATmega168, so compile for the ATmega168. You may also try defining "USB_INTR_VECTOR" as "INT0_vect" in "usbconfig.h", or replacing "SIG_INTERRUPT0" with "INT0_vect" in "usbdrvasm.S" (around line 60 in version 20090822). This problem may have already been fixed in version 20100715.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License