USBEHCI bug with high-bandwidth interrupt endpoints?

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: Aaron Rossetto (AaronRossetto_at_discussions.microsoft.com)
Date: 10/26/04

  • Next message: nir1408: "Re: Fatal bug in DDK sample?" 
    Date: Tue, 26 Oct 2004 13:11:08 -0700

    (I posted this yesterday but was not signed in as an MSDN subscriber. --atr)

    According to the USB 2.0 specification, section 5.9, an interrupt endpoint
    is capable of transmitting 24.5 MB/s by specifying three transactions per
    microframe with a maximum packet size of 1024 bytes in the endpoint
    descriptor and a bInterval value of 0x01. Despite the fact that my interrupt
    endpoint specified three transactions per microframe in the wMaxPacketSize
    field, I was only ever seeing one transaction per microframe with my USB
    analyzer. This was further confirmed by my performance test, which was
    returning 8 MB/s, that is, the fastest rate that can be achieved with a
    packet size of 1K and a bInterval value corresponding to 125 microseconds.

    What appears to be happening, as I will describe, is that the Microsoft USB
    driver is disregarding the multiplier bits for interrupt endpoints. I
    understand this is not a problem with isochronous endpoints, which also enjoy
    the same benefit. I am pleased to report, however, that I have discovered a
    workaround to get three transactions per microframe and thus the full 24.5
    MB/s throughput I originally
    desired. It is not for the faint of heart, however. I was lucky enough to
    have access to SoftICE, which helped me to discover the workaround and makes
    the procedure easy, but currently the procedure is manual. It could
    potentially be automated, but would be more involved.

    For reference, my host is a Dell-branded 2.5GHz P4 running Microsoft XP
    Service Pack 1a and the target device is a Cypress FX2 development board.
    The host controller is an Intel 82801DB/DBM.

    After plugging in my device, I used the 'usb -schedule' command in SoftICE
    to view the periodic frame list structure of the EHCI controller to which my
    device was attached. Each of the periodic frame list entries pointed to a QH
    (queue head) structure, which is expected behaviour per the EHCI
    specification for interrupt transfers. Each of the entires in the periodic
    frame list pointed to the very same QH
    structure; that is, each of the pointers pointed to the same block of
    memory. However, the multiplier field (DWORD 2, bits 31:30) of the QH
    structure did not reflect what I had set on the device's interrupt endpoint
    descriptor. The multiplier bits were indicating one transaction per
    microframe (00b), when they should have indicated three transactions per
    microframe (10b).

    Fortunately, SoftICE displays the address of the QH structure. Since all the
    periodic frame list entries pointed to the same address, I used the 'phys'
    command in SoftICE to translate the linear address of the QH structure to a
    virtual address where it resided in system RAM. With this address, I could
    open up a data window and manually change the two bits in question from 00b
    to 10b. Now issuing the 'usb
    -schedule' command showed the multiplier field to be 3 instead of 1.

    When I returned to Windows and ran my performance test, success!--very close
    to 24.5 MB/s. The USB analyzer showed three transactions per microframe,
    except in those cases where the host NAKed one of the data frames (in which
    case the USB specification says that the host will not reattempt the transfer
    until the beginning of the next microframe).

    Is Microsoft aware of this bug (or is it even a bug)? It doesn't seem to be
    addressed with SP2, since a test machine with SP2 also failed to program the
    QH properly. Obviously going behind the driver's back to change data
    structures isn't the safest thing to do. Perhaps a KB entry is in order
    since I spent a good week investigating the issue.

    Aaron

  • Next message: nir1408: "Re: Fatal bug in DDK sample?"

    Relevant Pages

    • An affordable USB development tool
      ... The Tracker 110 is a USB bus analyser which can record low-speed, ... Transactions can be expanded to show the individual packets ...
      (sci.electronics.misc)
    • An affordable USB development tool
      ... The Tracker 110 is a USB bus analyser which can record low-speed, ... Transactions can be expanded to show the individual packets ...
      (sci.electronics.equipment)
    • An affordable USB development tool
      ... The Tracker 110 is a USB bus analyser which can record low-speed, ... Transactions can be expanded to show the individual packets ...
      (sci.electronics.components)
    • An affordable USB development tool
      ... The Tracker 110 is a USB bus analyser which can record low-speed, ... Transactions can be expanded to show the individual packets ...
      (comp.arch.embedded)
    • USB Interrupt endpoint processing starved
      ... My own USB device driver. ... I have user mode code that is responding to data from the interrupt ... The user code continuously makes queries to the USB device via the ... the interrupt endpoint of the USB device fast enough such that the ...
      (microsoft.public.development.device.drivers)