PORTS Forum
Ports and Interfaces => USB => Topic started by: zero_one on June 11, 2015, 09:15:38 pm
-
Hi Jan,
I am new to USB. I have 1 Full Speed (12 Mbps) CDC-ACM type USB device connected directly to a High Speed (EHCI - 480 Mbps) controller on a SoC running Linux
When there is no user-space application opening the CDC-ACM device in linux, I see a pulse which is repeated every 1 ms (SOF?). Once an application (example cat) opens the CDC-ACM device, I see a lot of IN tokens (~102) between 2 SOF's from the host and the device NAKs the IN token. The NAKs are fine but the large number of IN tokens is keeping the device busy NAKing that it hampers its operation.
Q1: Is there a way to reduce the number of IN tokens within the 1 ms interval? Which parameter would it be ?
Thanks
0_l_0
lsusb output below
============
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 1 Single TT
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 3.03
iManufacturer 3 Linux 3.3.8 ehci_hcd
iProduct 2 Generic Platform EHCI Controller
iSerial 1 ehci-platform
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 12
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 1
wHubCharacteristic 0x0009
Per-port power switching
Per-port overcurrent protection
TT think time 8 FS bits
bPwrOn2PwrGood 10 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0103 power enable connect
Device Status: 0x0001
Self Powered
Bus 001 Device 002: ID 1546:01a7 U-Blox AG
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1546 U-Blox AG
idProduct 0x01a7
bcdDevice 1.00
iManufacturer 1 u-blox AG - www.u-blox.com
iProduct 2 u-blox 7 - GPS/GNSS Receiver
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 62
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 0
CDC Header:
bcdCDC 1.10
CDC ACM:
bmCapabilities 0x02
line coding and serial state
CDC Call Management:
bmCapabilities 0x03
call management
use DataInterface
bDataInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 255
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 255 Vendor specific
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0001
Self Powered
-
On interrupt endpoints, bInterval in the endpoint descriptor specifies the maximum latency, or time between transaction attempts.
Your device has only bulk endpoints so the CDC driver on the host decides how often to poll.
NAKs are typically low maintenance; the hardware returns NAK in response to IN token packets until firmware arms the endpoint to send data.
-
Hi Jan,
Thanks for the reply, but what about the interrupt endpoint in the listing, it has a bInterval of 255 ?
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 255
Nishanth
-
Sorry, I missed that. 255 is the maximum value, however.
-
If I manage to reduce the bInterval to say 16 from 255, would it reduce the number of IN packets between the SOFs ?
-
No, that would decrease the maximum latency from 255 ms to 16 ms. (The host can use any interval up to the maximum requested.)
If the IN token packets are to a bulk endpoint, bInterval has no effect.
-
Basically, you can't and it shouldn't be a problem.
Are you totally sure the NAKs are causing a problem, and can you configure it otherwise? As Jan mentions NAKs are typically handled in hardware and should be no problem to a device. They're usually totally invisible to the device's firmware, it can't tell if its hardware is NAKing or not. If your hardware is informing the firmware of the NAKs, I'd expect you'd be able to configure the endpoint not to do that.
Is that your problem? and is there a configuration you can do?
If that isn't your problem, then I'm not sure what you're getting at. NAKs (usually) cause no problems at all.