# This device cannot start. (Code 10) error in Windows 7

I'm trying to fix an error This device cannot start. (Code 10) with a USB HID device I'm building. Here are some details on my project:

IDE: MPLABX on Mac OS X
MCU: PIC32MX250F128B
Programmer: Microstick II
Git Repository: https://github.com/josefvanniekerk/pic32_usb

Please refer to the code above, it's not big, I'm trying not to flood the question with source code ;)

The device enumerates, and I'm able to see that Windows 7 and Mac OS X is able to identify the device.

However in Windows, I'm getting an error: This device cannot start. (Code 10)

I've been trying to fix this for a while. After redoing my breadboard wiring last week to try and improve the signal quality, I've come, trying to alter my code to get things working.

I'm using USB_INTERRUPT mode, and have my descriptor looks as follows:

ROM USB_DEVICE_DESCRIPTOR device_dsc =
{
0x12,                       // Descriptor size in bytes
USB_DESCRIPTOR_DEVICE,      // Device descriptor type
0x0200,                     // USB spec release number in BCD format
0x00,                       // Class code
0x00,                       // Subclass code
0x00,                       // Protocol code
USB_EP0_BUFF_SIZE,          // Max packet size for EP0
MY_VID,                     // Vendor ID
MY_PID,                     // Product ID
0x0001,                     // Device release number in BCD format
0x01,                       // Manufacturer string index
0x02,                       // Product string index
0x00,                       // Device serial number string index
0x01                        // Number of possible configurations
};


and the HID report discriptor, (built with HID Tool from usb.com):

ROM struct{BYTE report[HID_RPT01_SIZE];} hid_rpt01 =
{
{
0x05, 0x01,                    // USAGE_PAGE (Generic Desktop)
0x09, 0x04,                    // USAGE (Joystick)
0xa1, 0x01,                    // COLLECTION (Application)
0x09, 0x04,                    //   USAGE (Joystick)
0xa1, 0x00,                    //   COLLECTION (Physical)
0x05, 0x09,                    //     USAGE_PAGE (Button)
0x19, 0x01,                    //     USAGE_MINIMUM (Button 1)
0x29, 0x08,                    //     USAGE_MAXIMUM (Button 8)
0x15, 0x00,                    //     LOGICAL_MINIMUM (0)
0x25, 0x01,                    //     LOGICAL_MAXIMUM (1)
0x95, 0x08,                    //     REPORT_COUNT (8)
0x75, 0x01,                    //     REPORT_SIZE (1)
0x81, 0x02,                    //     INPUT (Data,Var,Abs)
0xc0,                          //     END_COLLECTION
0xc0                           // END_COLLECTION
}
};


The above represents a Joystick with one button, so I'm trying to start small. My HID report looks like this:

 typedef union _INPUT_CONTROLS_TYPEDEF
{
BYTE buttons;
} INPUT_CONTROLS;



I've also set the descriptor size to 28 bytes in usb_config.h:

#define HID_RPT01_SIZE 28


This is about the furthest I've come with this project ever, but I'm face to face with a brick wall, that won't budge. Any help would be much appreciated. The full contents of main.c is at my GitHub repository

I'm testing my device on both Mac and Windows 7 via VMWare. The Microstick II doesn't appear to have the best debugger, so debugging is limited.

What I've done is light up an LED on Pin 2 (RA0) when USBDeviceState == CONFIGURED_STATE, and all I know is that the device is in CONFIGURED_STATE, as the LED lights up a few moments after the device is plugged in. I also managed to get the following from the USBLizer trial version:

I can't set breakpoints in MPLABX, and halt the MCU to investigate the issue, because of USB clock timing requirements, so really stuck as to how I can troubleshoot and fix this.

For what it's worth, I've set a breakpoint for the EVENT_BUS_ERROR handler in main.c, and the following U1EIR registers' bits are set:

• DFN8EF - Data Field Size Error Flag bit
• CRC5EF_EOFE - CRC5 Host Error Flag bit
• PIDEF - PID Check Failure Flag bit

Am I getting these errors because I'v entered debug mode and the chip isn't happy, and these aren't the actual errors at all, and if these errors are in fact correct indications of my problem, what does it mean?

If I'm getting a DFN8EF - Data Field Size Error Flag bit, how do I figure out what data field is the wrong size? It's likely to be my descriptor, or HID report, but I can't find the fault.

I've managed to track down the issue. It was to do with my endpoint descriptor. I used a define PS_IN and PS_OUT where I should have used _PS_IN and _PS_OUT prefixed with an underscore.

This off course didn't result into a compiler error, since all four of these defines are in fact valid, yet _PS_IN != PS_IN etc.

I had the same error with a PIC18.

The issue was the oscillator quality. USB requires a tight tolerance on the oscillator frequency. I was using a ceramic one to feed the PIC PLL and it was not stable enough.

In another design, the issues was also due to the XTAL, the load caps were not of the right value and the frequency was some ppm off, which was sufficient to be detected by windows and reported as malfunctioning device.

Hope this would help.

• I'm using a 12MHz NSK crystal. Not sure if this is any good? It appears to have a freq stability of ±10 ~ ±50 ppm. I can't really find any details from the manufacturer on which caps to use with it etc, so I just picked 22pF. – josef.van.niekerk Jun 24 '13 at 21:47
• Find a way to measure your system frequency. But don't probe the XTAL pins, the added cap of the probe will alter the frequency. You may have a pin that can configured as clock out. Then use a spectrum analyser if you have access to that, or the FFT function of your scope to know the center frequency. then adjust the caps to have exactly the nominal. – Blup1980 Jun 26 '13 at 5:47
• By the way, If you have access to the datasheet, you should have the load capacitance somewhere. – Blup1980 Jun 26 '13 at 5:50
• Thanks, for the reply. Unfortunately I don't have an oscilloscope, so that's a no go for me. I've decided to build the circuit as a proper PCB, as the breadboard setup has too much parasitic capacitance, inductance etc. everywhere. – josef.van.niekerk Jun 26 '13 at 8:52