Re: TI Launchpad woes - CDC/ACM interface not starting

Thanks Russ.

This info is very helpful, I have been debugging kexts since a few days. I am OK with the device not being supported by windows, all I need is to modify my mac to work with the device, since that will not involve TI or Apple.

I will try to hack together some code to change the bDeviceClass on it, looks like that is the only thing that can be done now.

Harsha

On 11/4/2010 4:28 PM, Russ Winsper wrote:

Harsha,

I'll take this offline first.

The real problem is when multifunction devices have to run on both Windows and Mac. The CDC working group designed the CDC descriptor set with all the required information to find all the descriptors and configure a multifunction device correctly. Unfortunately Microsoft didn't follow the rules and then couldn't handle things correctly. They decide (unilaterally) to use the IAD descriptor to correct the problem for themselves.

So until our new driver (that supports IAD) is released we have a problem. If you define the bDeviceClass as CDC it won't run correctly on Windows. If you define it as Miscellaneous it won't run on Mac (for now). The longer term solution is to use the Miscellaneous class. Device class = 239, Device Subclass = 2 and Device Protocol = 1. That will eventually work on the Mac.

The other problem you have is the interfaces are also incorrect, this is just not CDC compliant.

Russ

------------------

On Nov 4, 2010, at 2:12 PM, Harsha Chenji wrote:

Russ,

Thanks for your quick reply. Since we cannot change the kernel code specially for this device, can we "fool" the kernel into reading the correct descriptors, given this particular VID/PID, via a rulebase of some sort? Something like an IF condition during probing.
Could you also please let us know what the correct descriptors should be (CDC and device) for valid recognition?

I am also trying to obtain the firmware from TI for re-defining these values. If you don't mind, I will let them know that the device descriptors for their device are wrong (bdeviceclass should be 2 or 239, CDC descriptors should be xxx).

Harsha

On 11/4/2010 4:03 PM, Russ Winsper wrote:

Unfortunately this is not even close to a CDC compliant device. There are two ways to define CDC devices, either with bDeviceClass of Communications Device Class (2) or using the Miscellaneous Device Class (239) with IADs, but this neither of those. Also the descriptors, in the interface that claims to be CDC, are also incorrect.

Sorry...

Russ

----------------------

On Nov 4, 2010, at 12:52 PM, Harsha Chenji wrote:

Attached. I am not on a Mac, so attached the USBView dump if it's OK...

----8<--------8<--------8<--------8<----

Device Descriptor:

bcdUSB:             0x0110

bDeviceClass:         0x00

bDeviceSubClass:      0x00

bDeviceProtocol:      0x00

bMaxPacketSize0:      0x08 (8)

idVendor:           0x0451 (Texas Instruments)

idProduct:          0xF432

bcdDevice:          0x0100

iManufacturer:        0x01

0x0409: "Texas Instruments"

iProduct:             0x02

0x0409: "Texas Instruments MSP-FET430UIF"

iSerialNumber:        0x03

0x0409: "B1FF41CE96105228"

bNumConfigurations:   0x01

ConnectionStatus: DeviceConnected

Current Config Value: 0x01

Device Bus Speed:     Full

Device Address:       0x01

Open Pipes:              5

Endpoint Descriptor:

bEndpointAddress:     0x82  IN

Transfer Type:   Interrupt

wMaxPacketSize:     0x0040 (64)

bInterval:            0xFF

Endpoint Descriptor:

bEndpointAddress:     0x03  OUT

Transfer Type:        Bulk

wMaxPacketSize:     0x0040 (64)

bInterval:            0xFF

Endpoint Descriptor:

bEndpointAddress:     0x83  IN

Transfer Type:        Bulk

wMaxPacketSize:     0x0040 (64)

bInterval:            0xFF

Endpoint Descriptor:

bEndpointAddress:     0x81  IN

Transfer Type:   Interrupt

wMaxPacketSize:     0x0040 (64)

bInterval:            0x01

Endpoint Descriptor:

bEndpointAddress:     0x01  OUT

Transfer Type:   Interrupt

wMaxPacketSize:     0x0040 (64)

bInterval:            0x01

Configuration Descriptor:

wTotalLength:       0x0055

bNumInterfaces:       0x02

bConfigurationValue:  0x01

iConfiguration:       0x00

bmAttributes:         0x80 (Bus Powered )

MaxPower:             0x32 (100 Ma)

Interface Descriptor:

bInterfaceNumber:     0x00

bAlternateSetting:    0x00

bNumEndpoints:        0x03

bInterfaceClass:      0x02

bInterfaceSubClass:   0x02

bInterfaceProtocol:   0x01

iInterface:           0x05

0x0409: "MSP430 Application UART"

Unknown Descriptor:

bDescriptorType:      0x24

bLength:              0x05

05 24 00 10 01 

Unknown Descriptor:

bDescriptorType:      0x24

bLength:              0x05

05 24 01 00 00 

Unknown Descriptor:

bDescriptorType:      0x24

bLength:              0x04

04 24 02 02 

Endpoint Descriptor:

bEndpointAddress:     0x82  IN

Transfer Type:   Interrupt

wMaxPacketSize:     0x0040 (64)

bInterval:            0xFF

Endpoint Descriptor:

bEndpointAddress:     0x03  OUT

Transfer Type:        Bulk

wMaxPacketSize:     0x0040 (64)

bInterval:            0xFF

Endpoint Descriptor:

bEndpointAddress:     0x83  IN

Transfer Type:        Bulk

wMaxPacketSize:     0x0040 (64)

bInterval:            0xFF

Interface Descriptor:

bInterfaceNumber:     0x01

bAlternateSetting:    0x00

bNumEndpoints:        0x02

bInterfaceClass:      0x03 (HID)

bInterfaceSubClass:   0x00

bInterfaceProtocol:   0x00

iInterface:           0x04

0x0409: "MSP430 Debug-Interface"

HID Descriptor:

bcdHID:             0x0101

bCountryCode:         0x00

bNumDescriptors:      0x01

bDescriptorType:      0x22

wDescriptorLength:  0x02B6

Endpoint Descriptor:

bEndpointAddress:     0x81  IN

Transfer Type:   Interrupt

wMaxPacketSize:     0x0040 (64)

bInterval:            0x01

Endpoint Descriptor:

bEndpointAddress:     0x01  OUT

Transfer Type:   Interrupt

wMaxPacketSize:     0x0040 (64)

bInterval:            0x01

----8<--------8<--------8<--------8<----

On 11/4/2010 2:48 PM, Russ Winsper wrote:

Harsha,
What is the Device class in the Device descriptor? Can you attach the USB Bus Probe for this device?

Thanks...
Russ
--------------------
On Nov 4, 2010, at 12:43 PM, Harsha Chenji wrote:

Howdy all,

Recently bought a TI Launchpad (getting popular nowadays) and connected it to my Macbook Pro (x64/10.6.4). The device presents itself as a composite device with 2 interfaces: a CDC/ACM/Control on #0 and a HID on #1. The CDC/ACM/Control interface on it has a tough time being recognized by the kernel.

Details: Interface #0 has a class of 2, subclass of 2 and a protocol of 1 (2/2/1 for short). Now, in AppleUSBCDC.kext's personalities, AppleUSBCDCACM is matched to 2/2/0 and not 2/2/1. I tried to correct this, but to no avail. The error I am getting is: "start - AppleUSBCDCACMControl: could not find driver".

I installed the USB debug enabled kexts, along with USB Prober. I have tracked down the error to the start method of AppleUSBCDCACMControl. In it, a call is made to findACMCDC, which essentially gets a matching dict from IOService and finds candidates for the driver. The criteria it uses though, is a match using class "AppleUSBCDC". However, no matching drivers are found, and the method returns NULL.

Why does this happen? Why doesnt the kernel recognize a CDC/ACM interface which is easily recognized by the cdc_acm kernel module on Linux?

One issue could be the IAD having a 0/0/0 descriptor. I read on of the old posts that it needs to have a class of 0xEF. In that case, is there any way to "fake" the class before the USB probes it, something like the udev rules on linux?

Thanks a lot,
Harsha
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Usb mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden