"Device Malfunction" Recommendations

[ryxxui]

I've been trying to get the "hid-data" example running on my ATMega328p for a few days now, and after overcoming some rather obnoxious hurdles I am again at an impasse. I have successfully gotten the code onto the microcontroller, but whenever I plug the system into the computer I receive a message from Windows (XP-32 and 7-64) that the device is malfunctioning, and I am not allowed to do anything else to the USB device through the operating system. I have tried to set up the circuit using both the zener diode method and the double diode method, as outlined in the circuit examples, and I am rather confident that the parts I am using (including all of the correct sizes of resistor and capacitor outlined) are working. I have also tried to run the circuit at 12MHz, 16MHz, and 20MHz (I have re-built the project and re-programmed the microcontroller each time).

Does anyone have any recommendations for how they have worked around the "Device Malfunction" issue? I am sure that what I am encountering could be any number of problems but perhaps other people have found a variety of potential issues that can cause this specific problem.

[Alan Chatham]

Just to make sure, is the error you get when you plug in your device "Device not recognized"? I'm not totally sure what you mean by "device malfunctioning", but if it's the "Device Not Recognized" error (a little tooltip box shows up in your system tray with a little pop sound, and in Device Manager, it shows up as Unknown Device), then there are a few things that can cause that. I'm sure you've checked some of them, but here's a list of some common ones. I guess we should probably start a wiki page listing basic solutions to common problems...

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 VUSB 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 VUSB, 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.

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 on the RESET line?

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().

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.

Those are the tips I've got; I'm sure some other people have some as well...

[RazorConcepts]

3. - EMI

So using an unshielded usb cable would probably mean huge issues? I am just using a custom made USB cable with wires soldered to the plug, and its about 3ft long. That could explain my issues

[christian]

Does Windows refer to the device by name? If it knows the device name, there has been some basic USB communication going on. If not, it's very likely that something very basic is broken.

[Alan Chatham]

So using an unshielded usb cable would probably mean huge issues? I am just using a custom made USB cable with wires soldered to the plug, and its about 3ft long.

Eeeehhh, it depends. (Sorry about taking so long to reply, I've been moving!) I've generally had no problem working on a breadboard with a USB cord that I cut and spliced individual wires to, but that section is only 6 inches or so. I did have problems with a longer cable (6 foot maybe?) that I cut and soldered to spots on my printed boards - I'd have connectivity issues with it if the metal braid inside the wire wasn't also soldered to ground on my board. And if you've got 3 feet of wire going all everywhere, unshielded, it could quite possibly be an issue. So my suggestion would be to get a USB cord, or the one you're using, and cut it to like a 6 inch length and just prototype from that distance? Or get a new longer cable and connect the outer metal shielding of it to ground as well.

Of course, EMI is a very complicated issue, and as an economics major with no EE background at all, I can hardly claim any knowledge in it. V-USB was the first thing I've worked on that's been somewhat sensitive to EMI; before I knew about adding some decoupling capacitors, I couldn't get it to work for the life of me. Oh, I also started a Troubleshooting page on the wiki, so if your problem winds up being something different, which it well could be, please add the solution to it!

[souravg009]

MY METABOARD DETECTED FINALLY!

I've checked my circuit for any errors. Hardware was OK. FUSE OK, HEX Burned OK. Still it was not being detected.
what I have done to solve the problem::
1. connected the jumper pin to ground.
2. connected the device to USB.
3. Power up the device.
4. Downloaded the latest driver for USBasploader.
5. Update the driver from "Device Manager" ( I use windows 7).
6. "reset" the MCU.
7. BINGO! it appears as "USBASP" under "libusb-win32 devices".

Its DONE.