dfu-util on windows with libusb-1.0

[Andrew Leech]

On 7/06/12 6:44 AM, Tormod Volden wrote:
> On Mon, Jun 4, 2012 at 3:51 AM, Andrew Leech wrote:
>> Hi,
>> I'm just starting to use dfu-util to program some hardware based on the
>> lpc3131 processor which has a built in dfu mode.

>> Unfortunately I can't make it work with any new dfu-util compiled from
>> source (git).
>>
>> The new versions all rely on libusb-1.0 as far as I can tell, which on
>> windows is currently limited to WinUSB backend driver which does not support
>> usb reset. This usb reset certainly appears to be required on my lpc3131 to
>> start the loaded code, is this the same on other dfu device?
> Hi Andrew,
>
> Is it the -R option, performing the libusb_reset_device() that fails?
> Does it otherwise work? Does the device need a USB reset to program
> the device, or can it start the loaded code if you manually reset the
> device?
It certainly was the -R that failed, everything up to that point runs 
fine. It looks like the reset command doesn't actually return an error, 
it just doesn't do anything.
My code doesn't start up without the reset command, and manually 
resetting the chip just takes me straight back to the bootloader as far 
as I can tell.
>> I was able to compile against libusbx instead thinking it supported the
>> libusb-win32 driver but alas no, I don't think libusb-win32 or libusbk
>> backend drivers are expected to be supported for a little while still.
>> I looked into libusbk as an option also, but it doens't support the
>> libusb-1.0 api yet, although it's planned to in the future.
>> Apparently there's proposed patches to libusb-1.0 to support the original
>> libusb-win32 driver somewhere too, although I couldn't find the patches
>> myself to try them.
>>
>> Has anyone else seen these kinds of issues.... is dfu-util used on windows
>> typically?
> Thanks for looking at these alternative backends. I think a number of
> projects use dfu-util for Windows, but they might not need the -R
> option. It is sad that libusb 1.0 on Windows is so out of sync
> featurewise, especially since the libusb developers have been
> recommending libusb 1.0 for so long.
>
> Would it be a possible workaround, although not elegant, to have a
> helper program using libusb 0.1 to simply issue a USB reset after
> using the stock dfu-util to download the firmware?
I can't see this working, as a libusb 0.1 program would need a different 
driver to the libusb 1.0, neither of them can use any one driver.
> Or would you in
> that case be better off sticking to the old 0.1 version? If it works
> fine with your device, there is maybe no need to use a later version
> either. Of course, we would like to have the latest code work for
> everybody so I hope the WinUSB limitations can be worked around
> eventually.
>
> Cheers,
> Tormod
>
Did you see my follow up email?
http://lists.openmoko.org/pipermail/devel/2012-June/007253.html

I have actually got it working with the pbatard K personal branch of 
libusb and the libusbk.sys driver. This is working great for me, looking 
to be very reliable.

It does appear that libusbx will get libusbk.sys support in the coming 
months, and libusbk may/will get libusb-1.0 api support sometime 
soonish, so in the not too distant future there should be a couple of 
options for using a supported usb library on windows. I'd lean towards 
libusbx myself, as it's shaping up to be the 'official' replacement for 
libusb, it looks like a few linux distros will/have switched to that 
already (fedora, arch).

I did look briefly into porting dfu-util to libusbk but I think the api 
really is just too different, it wouldn't be easy to support both libusb 
and libusbk seamlessly. Presumably it would be easier to backport 
dfu-util to use libub-0.1 api and then use libusbk in compatibility 
mode, but that still stuffs up linux support. I think it's far better to 
just use the custom libusb for now.

Thanks,
Andrew