Hi everybody,
due to lots of work and tight schedules I just couldn’t reply on your suggestions. Here we go…
@ Mike: Thanks for the info. It made me digging deaper into USB specs…
@ Gus:
I was very pleased for your suggestions sending in the board. Unfortunately it’s a prototype board of a companie’s custom solution using MSP430 F5529 and it’s too late sending in the board, anyway.
So, for your knowledge, here are the hard facts:
Here’s a USB Descriptor Dump of the board attached to Windows 7 USB Host:
[em]
Information for device SDHx (VID=0x2047 PID=0x03F0):
Connection Information:
Connection status: Device connected
Device actual bus speed: Full
Device is hub: No
Device adress: 0x0002
Current configuration value: 0x01
Number of open pipes: 3
Device Descriptor:
0x12 bLength
0x01 bDescriptorType
0x0200 bcdUSB
0x02 bDeviceClass (Communication Device Class)
0x00 bDeviceSubClass
0x00 bDeviceProtocol
0x08 bMaxPacketSize0 (8 Bytes)
0x2047 idVendor
0x03F0 idProduct
0x0200 bcdDevice
0x01 iManufacturer "SCHUNK"
0x02 iProduct "SDHx"
0x03 iSerialNumber "075F994625001400"
0x01 bNumConfigurations
Configuration Descriptor:
0x09 bLength
0x02 bDescriptorType
0x0043 wTotalLength
0x02 bNumInterfaces
0x01 bConfigurationValue
0x04 iConfiguration "SCHUNK SDHx"
0x80 bmAttributes (Bus-powered Device)
0x32 bMaxPower (100 mA)
Interface Descriptor:
0x09 bLength
0x04 bDescriptorType
0x00 bInterfaceNumber
0x00 bAlternateSetting
0x01 bNumEndPoints
0x02 bInterfaceClass (Communication Device Class)
0x02 bInterfaceSubClass (Abstract Control Model)
0x01 bInterfaceProtocol (ITU-T V.250)
0x05 iInterface “SCHUNK SDHx virtual COM Port”
CDC Header Functional Descriptor:
0x05 bFunctionalLength
0x24 bDescriptorType
0x00 bDescriptorSubtype
0x0110 bcdCDC
CDC Call Management Functional Descriptor:
0x05 bFunctionalLength
0x24 bDescriptorType
0x01 bDescriptorSubtype
0x00 bmCapabilities
0x01 bDataInterface
CDC Abstract Control Management Functional Descriptor:
0x04 bFunctionalLength
0x24 bDescriptorType
0x02 bDescriptorSubtype
0x02 bmCapabilities
CDC Union Functional Descriptor:
0x05 bFunctionalLength
0x24 bDescriptorType
0x06 bDescriptorSubtype
0x00 bControlInterface
0x01 bSubordinateInterface(0)
Endpoint Descriptor:
0x07 bLength
0x05 bDescriptorType
0x81 bEndpointAddress (IN Endpoint)
0x03 bmAttributes (Transfer: Interrupt / Synch: None / Usage: Data)
0x0040 wMaxPacketSize (64 Bytes)
0xFF bInterval
Interface Descriptor:
0x09 bLength
0x04 bDescriptorType
0x01 bInterfaceNumber
0x00 bAlternateSetting
0x02 bNumEndPoints
0x0A bInterfaceClass (CDC Data)
0x00 bInterfaceSubClass
0x00 bInterfaceProtocol
0x00 iInterface
Endpoint Descriptor:
0x07 bLength
0x05 bDescriptorType
0x02 bEndpointAddress (OUT Endpoint)
0x02 bmAttributes (Transfer: Bulk / Synch: None / Usage: Data)
0x0040 wMaxPacketSize (64 Bytes)
0xFF bInterval
Endpoint Descriptor:
0x07 bLength
0x05 bDescriptorType
0x82 bEndpointAddress (IN Endpoint)
0x02 bmAttributes (Transfer: Bulk / Synch: None / Usage: Data)
0x0040 wMaxPacketSize (64 Bytes)
0xFF bInterval
String Descriptor Table
Index LANGID String
0x00 0x0000 0x0409
0x01 0x0409 "SCHUNK"
0x02 0x0409 "SDHx"
0x03 0x0409 "075F994625001400"
0x04 0x0409 "SCHUNK SDHx"
0x05 0x0409 "SCHUNK SDHx virtual COM Port"
0xEE 0x0000 Request failed with 0x0000001F
Connection path for device:
Renesas Electronics USB 3.0 Host Controller
Root Hub
Renesas Electronics USB Hub
SDHx (VID=0x2047 PID=0x03F0)
Brought to you by TDD v1.83.0, Mar 7 2014, 14:22:05
[/em]
The important things are:
- The device uses Bulk operations of max 64Byte PacketSize in 12MBit (FullSpeed) mode
- It’s sending (I used a S/W protocol analyzer) on the IN Endpoint NOT completely filled Packets.
- The protocol used, is a very simple ASCII protocol, which uses CR/LF pairs as EOL and as a End of Command/Response separator, no length field, nothing (ugly, I know…) (Side note - I’m a communication engineer…)
- The Host issues a Command and the Client responds to it. This response seems to be split in lines and each line makes a Packet
- Five devices are connected to the Host and communicate in parallel
What I did, so far:
I implemented the protocol and the driver for a single device, only.
As soon as the device gets connected as a UsbSerial device, I adjust the WorkerInterval to 1.
I set up internal buffers big enough to handle any data, start a communication thread (ComThread) with Prio AboveNormal (I also tried Highest) and setup DataReceived and Disconnected handlers.
When the Host issues a command, it copies it to an internal (ComThread) shared buffer and awakes the ComThread by signalling an event.
The ComThread Writes the data out over the Port and (directly afterwards) waits for an ResponseReceivedEvent to be signalled.
Each time the DataReveived handler gets invoked, it will append the received data to an internalRcvBuffer .
The ResponseReceivedEvent will eventually be set in the DataReveived handler when all expected data will be successfully received.
The ComThread becomes awakened and copies the internalRcvBuffer to the ReceivedText field.
From my Point of view, there is nothing wrong with this approach but data loss occurs - even if only one out of five devices are connected!
Today, I saw a new firmware version is ready for downloading. I will give it a try and will leave a comment whether it works, or not.
Cheers,
Rolf