Re: [libusb] Windows composite device fix

[<Phi...@mi...>]

Xiaofan is correct concerning DFU mode. When a host instructs a device, which is in "run-mode" (normal operation). to go into DFU mode via the DFU_DETACH command, the device will eventually go off-line and re-enumerate into DFU mode. I would highly recommend that the "DFU device" have a unique PID. In this case, under Windows, you can provide an INF that will direct Windows to use WinUSB or whatever you want to allow you access to EP0 (endpoint zero) on that device (which is the only endpoint that will be available).

Information regarding DFU can be found in the document, "Universal Serial Bus Device Class Specification for Device Firmware Upgrade", Version 1.1, dated 05 August 2004 (which is the latest revision), taken from http://www.usb.org/developers/docs/devclass_docs and the item "Device Firmware Upgrade Group".



________________________________________
From: Xiaofan Chen [xia...@gm...]
Sent: Saturday, April 28, 2018 7:15 AM
To: libusb-devel
Subject: Re: [libusb] Windows composite device fix

On Sat, Apr 28, 2018 at 5:27 PM, Paul Qureshi <pa...@wo...> wrote:
> Hi Xiaofan.
>
> On Sat, 28 Apr 2018 at 05:44, Xiaofan Chen <xia...@gm...> wrote:
>
>> 1) If you have the control of the FW, make the DFU to be of interface 0
>> and the HID interface to be of Interface 1. This will probably work for
>> your use case.
>
> I will try this on Monday when I'm back at work. If that fixes it then that
> would be a good solution for me.
>
> Thinking about it, I wonder if I could add DFU functionality to the HID
> interface... Windows will probably not like it, but really all it needs is
> the descriptors and some code to handle the control requests to that
> endpoint.

Actually I think DFU class and HID are mutual exclusive. You
can of course use HID for firmware upgrade, but then it will not
be called DFU. In fact, Microchip is using HID class for its bootloader
function and they use HIDAPI and QT to build the cross-platform
host program.

HIDAPI is the cross platfrom API for HID device.

>> 2) Write a DFU application based on WinUSB or libusbK API, still
>> use the WinUSB driver
>
>> 3) Write a DFU driver (ST has one, Atmel has one as well).
>> http://www.st.com/en/development-tools/stsw-stm32080.html
>
>> 4) Try to use libusb0.sys filter driver with libusb, I think it may work
>> even though there were issues with it. libusbK works fine with it
>> and therefore supposedly the Windows backend should work fine
>> but apparently there are something not right here.
>> https://github.com/libusb/libusb/issues/94

Take note this is still using libusb API.

>> 5) Try to check if usbdk works or not, if not extend it to support
>> USB composite device

Take note this is still using libusb API.

> I would prefer to keep it cross platform.

Take note that Option 4/5 are still using libusb API.

>
>> 6) To rework the Windows backend code to better deal with
>> USB composite device.
>
> I would be happy to do that, but it's a rather complex a poorly documented
> bit of code with heavy abstraction that makes it difficult to work with.
>
> Can anyone suggest a good way to modify the backend? It seems like it needs
> some way to interact with the composite driver and redirect attempts to
> access other interfaces.
>



--
Xiaofan

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
libusb-devel mailing list
lib...@li...
https://lists.sourceforge.net/lists/listinfo/libusb-devel