none
USB low speed device interrupt transfer packet size restriction changed on Windows 7

    Question

  • Hello,

    I work for a hardware manufacturer that produces devices with USB connectivity.  The device allows firmware to be upgraded through the USB port.  When in firmware upgrade mode, the firmware on the device enumerates the USB low speed device as an HID device and communicates via Interrupt transfer utilizing IN and OUT transfer on endpoint 1.  The interrupt IN and OUT endpoints are configured as 64 byte buffers.  This violates the USB spec.  Unfortunately I was unaware of this violation until recently when I discovered that Windows 7 (and possibly Vista, although I haven't tried it) no longer allow the device to enumerate with this incorrect configuration.

    I have corrected this issue for new models, but we have a large installed base of existing models in the field that have the old firmware which does not work with Windows 7.

    I believe the only solution to this lies in developing a USB driver that bypasses the interrupt transfer packet size limitation imposed on USB low speed devices.  I have attempted to use WinUSB as a generic driver to communicate with the device, but unfortunately the device still does not enumerate on Windows 7 (though it does work fine on Windows XP.)  I also attempted to use LibUSB as a generic USB driver, and in the case of LibUSB, the device does enumerate on Windows 7, but when I attempt to send packets to the Interrupt pipe, I get Win32 exceptions, likely due to the same restriction (again, I was able to get the device to communicate fully through libusb on Windows XP). 

    The third approach I have taken to resolving this issue was to utilize Windows XP mode to connect to the device.  Unfortunately Windows XP mode does not support HID devices, so again I am stuck.  I have also attempted to utilize WinUSB and LibUSB through Windows XP mode, but unfortunately Windows XP mode does not detect the USB device with either of these drivers installed.

    I think the only possibility remaining for me is to write a kernel mode USB driver for the device, but I'm afraid to invest the time to develop something like that if a lower level Windows interface is preventing the device from communicating due to the USB spec violation.

    Is there anything I can do?

     

    I realize this is a very in depth question and likely I would have to talk directly with a USB driver developer at Microsoft to deal with this issue.

    I have attempted to reach out to other USB developers at the following forum with no luck:

    http://www.lvr.com/forum/index.php?topic=402.0

     

    Thank you,

    Joe Dunne

    Monday, April 11, 2011 5:29 PM

Answers

  • If I understand your motivation correctly, you decided to use HID to download your firmware rather than DFU (Device Firmware Upgrade) because you didn't want to write a driver.  Now you're proposing to write a bus driver?  A bus driver is orders of magnitude more difficult to write than a function driver.  Using a VM won't work, because it still relies on the host machine's bus driver.

    The USB bus driver has become very pedantic, and enforces the USB spec, and I do not believe there is any way around it (I did look about a year ago, because I had a similar problem with a hobby project I was working on).

    A non-Windows solution would be to buy one of the ARM-based demo/evaluation boards (~$30-$50) that can also act as a host, and modify the USB stack to allow it to talk to your non-compliant device and download its new firmware.  Depending upon how many of these things you need to upgrade in the field, this may be the cheapest solution.  A customer asked me to write a blog about getting one of them setup, which you can find here: http://gadgetengineering.wordpress.com/  There is a bit of a learning curve (be sure to buy a JTAG interface so you can debug), but once you get going it isn't bad.

     -Brian

     


    Azius Developer Training, Windows driver, internals, and security training See www.azius.com for information
    Monday, April 11, 2011 9:48 PM

All replies

  • If I understand your motivation correctly, you decided to use HID to download your firmware rather than DFU (Device Firmware Upgrade) because you didn't want to write a driver.  Now you're proposing to write a bus driver?  A bus driver is orders of magnitude more difficult to write than a function driver.  Using a VM won't work, because it still relies on the host machine's bus driver.

    The USB bus driver has become very pedantic, and enforces the USB spec, and I do not believe there is any way around it (I did look about a year ago, because I had a similar problem with a hobby project I was working on).

    A non-Windows solution would be to buy one of the ARM-based demo/evaluation boards (~$30-$50) that can also act as a host, and modify the USB stack to allow it to talk to your non-compliant device and download its new firmware.  Depending upon how many of these things you need to upgrade in the field, this may be the cheapest solution.  A customer asked me to write a blog about getting one of them setup, which you can find here: http://gadgetengineering.wordpress.com/  There is a bit of a learning curve (be sure to buy a JTAG interface so you can debug), but once you get going it isn't bad.

     -Brian

     


    Azius Developer Training, Windows driver, internals, and security training See www.azius.com for information
    Monday, April 11, 2011 9:48 PM
  • jdunne525 wrote:
    >
    >I work for a hardware manufacturer that produces devices with USB
    >connectivity.  The device allows firmware to be upgraded through the
    >USB port. ...The interrupt IN and OUT endpoints are configured as 64
    >byte buffers.  This violates the USB spec. 
    >...
    >I have corrected this issue for new models, but we have a large
    >installed base of existing models in the field...
    >
    >I believe the only solution to this lies in developing a USB driver
    >that bypasses the interrupt transfer packet size limitation imposed
    >on USB low speed devices.
     
    That's too late.  You can't write a driver to fix this.  The device is not
    going to enumerate on Windows 7, so the operating system will never even
    TRY to load a driver.  It doesn't matter what kind of driver you write.
    You'll never get past the host controller driver.
     
    >Is there anything I can do?
     
    I'm afraid not.  Basically, you are screwed.  You will have to instruct
    people to find an XP system to update the firmware.
    --
    Tim Roberts, timr@probo.com
    Providenza & Boekelheide, Inc.
     

    Tim Roberts, DDK MVP Providenza & Boekelheide, Inc.
    Wednesday, April 13, 2011 7:01 AM
  • Brian and Tim,

     

    It appears you are both correct and I am in fact screwed.  We've decided to rework the units by manually pulling the chips and reprogramming them.  Thank you both for your input on the issue.  It is very unfortunate that there is no way around this issue.

     

    Joe

    Wednesday, April 13, 2011 6:40 PM