CDC-ACM driver reducing IN tokens

[zero_one]

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

[Jan Axelson]

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.

[zero_one]

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

[Jan Axelson]

Sorry, I missed that. 255 is the maximum value, however.

[zero_one]

If I manage to reduce the bInterval to say 16 from 255, would it reduce the number of IN packets between the SOFs ?

[Jan Axelson]

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.

[Barry Twycross]

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.