USB Enumeration problem on PIC18F4550 with CCS USB CDC

[nuwavedc]

I've been battling a virtual comm port USB problem for a while now the problem seems to be related to enumeration. Customer is really frustrated and I don't know what else to try. Need some help from USB experienced engineer.

Here are the symptoms:

When USB is connected the found new hardware box pops up with garbage characters instead of the proper identifier. I can get it working by pointing widows to the .inf file for a VCP.

If I connect the usb link directly from our hardware to the PC no problem, if I insert an external hub or active hub/cable extender there are issues.

Here is the resultant log text from the MS UVCView.x86.exe utility:

Unsuccessful Enumeration:
_______________________________________________________
---===>Device Information<===---
*!*ERROR: no String Descriptor for index 2!

ConnectionStatus: FailedEnumeration
Current Config Value: 0x00 -> Device Bus Speed: Low
Device Address: 0x00
Open Pipes: 0
*!*ERROR: No open pipes!

===>Device Descriptor<===
bLength: 0x12
bDescriptorType: 0x01
bcdUSB: 0x0110
bDeviceClass: 0x02
*!*ERROR: Device enumeration failure
____________________________________________________________



Successful enumeration (direct, no hub):
____________________________________________________________
---===>Device Information<===---
*!*ERROR: The index selected does not support English(US)

ConnectionStatus:
Current Config Value: 0x01 -> Device Bus Speed: Full
Device Address: 0x01
Open Pipes: 3

===>Endpoint Descriptor<===
bLength: 0x07
bDescriptorType: 0x05
bEndpointAddress: 0x81 -> Direction: IN - EndpointID: 1
bmAttributes: 0x03 -> Interrupt Transfer Type
wMaxPacketSize: 0x0008 = 0x08 bytes
bInterval: 0xFA

===>Endpoint Descriptor<===
bLength: 0x07
bDescriptorType: 0x05
bEndpointAddress: 0x02 -> Direction: OUT - EndpointID: 2
bmAttributes: 0x02 -> Bulk Transfer Type
wMaxPacketSize: 0x0040 = 0x40 bytes
bInterval: 0x01

===>Endpoint Descriptor<===
bLength: 0x07
bDescriptorType: 0x05
bEndpointAddress: 0x82 -> Direction: IN - EndpointID: 2
bmAttributes: 0x02 -> Bulk Transfer Type
wMaxPacketSize: 0x0041 = 0x41 bytes
bInterval: 0x01

===>Device Descriptor<===
bLength: 0x12
bDescriptorType: 0x01
bcdUSB: 0x0110
bDeviceClass: 0x02 -> This is a Communication Device
bDeviceSubClass: 0x00
bDeviceProtocol: 0x00
bMaxPacketSize0: 0x40 = (64) Bytes
idVendor: 0x04D8idProduct: 0x000A
bcdDevice: 0x0100
iManufacturer: 0x01
English (United States) "CCS"
iProduct: 0x02
iSerialNumber: 0x00
bNumConfigurations: 0x01

===>Configuration Descriptor<===
bLength: 0x09
bDescriptorType: 0x02
wTotalLength: 0x0043 -> Validated
bNumInterfaces: 0x02
bConfigurationValue: 0x01
iConfiguration: 0x00
bmAttributes: 0xC0 -> Bus Powered
MaxPower: 0x32 = 100 mA

===>Interface Descriptor<===
bLength: 0x09
bDescriptorType: 0x04
bInterfaceNumber: 0x00
bAlternateSetting: 0x00
bNumEndpoints: 0x01
bInterfaceClass: 0x02 -> This is Communications (CDC Control) USB Device Interface Class
bInterfaceSubClass: 0x02
bInterfaceProtocol: 0x01
CAUTION: This may be an invalid bInterfaceProtocol
iInterface: 0x00
-> This is a Communications (CDC Control) USB Device Interface Class

===>Descriptor Hex Dump<===
bLength: 0x05
bDescriptorType: 0x24
05 24 00 10 01
-> This is a Communications (CDC Control) USB Device Interface Class

===>Descriptor Hex Dump<===
bLength: 0x04
bDescriptorType: 0x24
04 24 02 02
-> This is a Communications (CDC Control) USB Device Interface Class

===>Descriptor Hex Dump<===
bLength: 0x05
bDescriptorType: 0x24
05 24 06 00 01
-> This is a Communications (CDC Control) USB Device Interface Class

===>Descriptor Hex Dump<===
bLength: 0x05
bDescriptorType: 0x24
05 24 01 00 01

===>Endpoint Descriptor<===
bLength: 0x07
bDescriptorType: 0x05
bEndpointAddress: 0x81 -> Direction: IN - EndpointID: 1
bmAttributes: 0x03 -> Interrupt Transfer Type
wMaxPacketSize: 0x0008 = 0x08 bytes
bInterval: 0xFA

===>Interface Descriptor<===
bLength: 0x09
bDescriptorType: 0x04
bInterfaceNumber: 0x01
bAlternateSetting: 0x00
bNumEndpoints: 0x02
bInterfaceClass: 0x0A -> This is a CDC Data USB Device Interface Class
bInterfaceSubClass: 0x00
bInterfaceProtocol: 0x00
CAUTION: This may be an invalid bInterfaceProtocol
iInterface: 0x00

===>Endpoint Descriptor<===
bLength: 0x07
bDescriptorType: 0x05
bEndpointAddress: 0x02 -> Direction: OUT - EndpointID: 2
bmAttributes: 0x02 -> Bulk Transfer Type
wMaxPacketSize: 0x0040 = 0x40 bytes
bInterval: 0x01

===>Endpoint Descriptor<===
bLength: 0x07
bDescriptorType: 0x05
bEndpointAddress: 0x82 -> Direction: IN - EndpointID: 2
bmAttributes: 0x02 -> Bulk Transfer Type
wMaxPacketSize: 0x0041 = 0x41 bytes
bInterval: 0x01
_____________________________________________________________
_________________
Thanks,

NuWaveDC

[Ttelmah]

Most likely problem, for this is insufficient capacitance on the Vusb pin, or overloading the USB power line, if you are running your circuitry directly from USB power.
Second (but made less likely by the hub making it worse), is that the clock is out of spec. The frequency must be within 1 part in 10000, for reliable USB operation.

Best Wishes

[nuwavedc]

Thanks for the Input Ttelmah. It is appreciated.

Here is what I can tell you:
-Our hardware has its own power
-Vusb is 3.35V steady, with a 0.1uF ceramic capacitor 0.1" from the micro, tried adding 1uF Tantalum in addition - no affect.
-Oscillator is from a 24.000MHz crystal
-Traces were a little long (although signals looked very clean), just to be sure I tried attaching usb connector directly to processor pins D+ and D- no affect.

I am 99% sure this is some kind of software related issue with the CDC or the compiler. Can anyone share a similar experience?
_________________
Thanks,

NuWaveDC

[FvM]

It rather looks like the string descriptor table is actually incorrect, as reported by the tool. That's likely to happen, if you don't understand how the length codes have to be set when editing the strings. You may start with the CCS provided example strings, they should be displayed correctly, as far as I remember. There may be other problems too, but I would start solving this problem.

[nuwavedc]

This looks like it may be a compiler issue. A previous hex file from an older version of the compiler worked fine enumerated fine. Same source compiled with an up to date version did not enumerate properly.
_________________
Thanks,

NuWaveDC

[FvM]

If the USB device is operating correctly when connected to a primary USB port, does it mean, all string descriptors are correctly displayed in USBView? I didn't understand this clearly from your post. So if everyhing is correct in this case I would neither expect a compiler nor other software problem.

Tracing the low level USB communication with an USB software monitor can help to see what's tranmitted wrong at the USB. However, cause the USB data transfer is error checked, you rather get a misbehaving device suspended by the host than receiving faulty data. A processing error inside the 18F4550 may be undetected by the host, but there are very few possibilities, how this should depend on different a port connection.

As another test for possible software problems, does an original CCS example code show the same behaviour?

[Guest]

[nuwavedc]

Can someone please tell me how I can configure the USB CDC for low speed mode? I am still having intermittent enumeration issues at high speed and would like to try testing some things at low speed as well.

Simply setting the #define USB_USE_FULL_SPEED FALSE is not working. We get enumeration issues with that as well. Our clock is an external 24MHz oscillator and we have PLL6
_________________
Thanks,

NuWaveDC

[nuwavedc]

Here was the problem for future searches on this topic:

1)Interrupt priorites were restructured to give the USB peripheral the highest priority interrupt.

2)The internal processor clock divider was selected too slow @ 8MHz, changed to 48MHz (the usb peripheral was setup with the right oscillator and was not changed).

Enumerates very reliably through hubs, extension cables, etc.]


Does not work on vista, see my other post.

Thanks for all of the suggestions.
_________________
Thanks,

NuWaveDC

[nuwavedc]

http://www.ccsinfo.com/forum/viewtopic.php?t=38092
_________________
Thanks,

NuWaveDC