Menu
▾
▴
Re: [libusb] Windows composite device fix
|
From: David G. <dav...@gm...> - 2018-05-30 15:30:34
|
> The issue is that WinUSB only supports composite devices where all > the interfaces use the WinUSB driver. If you try to have something like > an HID device with WinUSB for the DFU interface, it just doesn't work. > You can't open the WinUSB interface. WinUSB works fine on composite devices and I've released several products relying on this. I don't know what stumbling blocks you were encountering but here is the driver for our latest composite WinUSB device, which has WinUSB on interface 0, and two CDC ACM ports on interfaces 1 through 4. https://github.com/pololu/pololu-jrk-g2-software/blob/master/drivers/jrk-g2.inf Do you know what Windows API function was failing when you tried to access the composite WinUSB device, and what the error code was? My libusbp library does report this kind of information when there is an error so you could try accessing your device with libusbp and you might get some useful information. > I also looked at ways to create a new but at least consistent runtime > bootloader protocol, but because of this limitation of WinUSB there isn't > one. You would need to have a separate protocol for HID, CDC, mass storage > and every other type of device. Maybe you already thought of this, but you would just need one command to get each of those different device types into bootloader mode, and then after that it could appear as a new non-composite device with one native USB interface, and then you can use a richer set of commands to actually operate on it as a bootloader. For example, for a CDC device, you could connect to it and set the baud rate to some special value as a signal to go into bootloader mode. --David On Wed, May 30, 2018 at 8:15 AM, <Phi...@mi...> wrote: > We have the capability of using WinUSB and DFU when updating composite devices. > > The device's firmware would be bumped into DFU mode by the normal DFU_DETACH (setup) command or by any other mechanism you might want to employ. When your device re-enumerates into DFU mode (which will have a different PID), then that VID/PID can be specified in an INF file to use WinUSB (which can be used to access EP0, which is the only endpoint that DFU uses). > > This is regardless of the configuration of the device in non-DFU (normal operation) mode, be that HID, CDC, bulk or whatever other endpoints that configuration might contain (as a composite device). Your "normal" device's configurations no longer apply when your device is in DFU mode. > > Yes, you need an INF that specifies the VID and DFU PID to be handled by WinUSB, but this is a pretty trivial matter (unless you want absolutely no drivers involved). > > Am I missing something here? > > ________________________________________ > From: Paul Qureshi [pa...@wo...] > Sent: Wednesday, May 30, 2018 7:19 AM > To: lib...@li... > Subject: Re: [libusb] Windows composite device fix > > I'm back now, and have spent a bit more time on this problem. > > In short I think composite devices are not well supported on Windows, and > full DFU support is probably impossible with WinUSB. > > The issue is that WinUSB only supports composite devices where all the > interfaces use the WinUSB driver. If you try to have something like an HID > device with WinUSB for the DFU interface, it just doesn't work. You can't > open the WinUSB interface. Therefore, DFU cannot be supported for another > other than pure WinUSB devices. > > I also looked at ways to create a new but at least consistent runtime > bootloader protocol, but because of this limitation of WinUSB there isn't > one. You would need to have a separate protocol for HID, CDC, mass storage > and every other type of device. This has also scuppered my plan to have an > HID device with WinUSB bulk endpoints. > > There is nothing that can be done to fix libusb because the problem is with > WinUSB. The only solutions all involve installing alternative drivers. > > I'm giving up. > > Regards, > Paul Qureshi > > On Thu, 3 May 2018 at 09:05, Paul Qureshi <pa...@wo...> wrote: > >> Hi Tim. > >> On Wed, 2 May 2018 at 18:41, Tim Roberts <ti...@pr...> wrote: > >> > Of course it is. WinUSB handles composite devices and multiple >> > interfaces. It just requires an INF. > >> Yes, I was talking in the context of having the alternative driver > selected >> via WCID. This does not seem to be possible, only WinUSB can be selected. > >> INF files are an unsatisfactory solution, especially for open source >> projects where the cost of getting them signed is prohibitive. More over, >> users prefer devices that "just work" and don't require manual driver >> installation. That is particularly true of things like keyboards and mice. > >> So the goal here is to find a solution that works with WCID. Ideally >> without GUIDs too, because code space in a 4k bootloader is tight. > >> > Now, there may be a slimy way to handle this. In the Enum tree of the >> > registry, each device has a "Service" entry that identifies the driver >> > service that will handle the device. It is possible to overwrite that >> > entry on the fly, then restart the device. When it comes back it, it >> > will load the alternative driver. You could do the DFU thing, then >> > rewrite the Service entry back to "usbccgp". You'd have to make sure >> > the entries for WinUsb were properly set up, but it might work. > >> At the moment I am prototyping some WinUSB code to see what is possible > and >> if it could possibly be integrated into libusb somehow. libusb is aware of >> the sub-interfaces, but it sees them as already being claimed by the >> composite driver. Perhaps there is a way to find the correct sub-device at >> that stage. Alternatively, perhaps it would be possible to open the sub >> device with a special open function that takes the interface number. > >> If none of that proves possible then a new WinUSB based DFU utility is the >> next option. I will be away for a few weeks so there won't be any progress >> this month. > >> Regards, >> Paul > > ------------------------------------------------------------------------------ > 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 > > ------------------------------------------------------------------------------ > 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 |
