dfu-util on windows with libusb-1.0
lists.tormod at gmail.com
Wed Jun 6 22:44:26 CEST 2012
On Mon, Jun 4, 2012 at 3:51 AM, Andrew Leech wrote:
> I'm just starting to use dfu-util to program some hardware based on the
> lpc3131 processor which has a built in dfu mode.
> My device is predominantly used on windows, but I've had reliability isuues
> with the dfu software that's supplied by NXP.
> On windows, I can use an old binary I downloaded:
> $ ../dfu-util.exe -V
> dfu-util - (C) 2007 by OpenMoko Inc.
> This program is Free Software and has ABSOLUTELY NO WARRANTY
> dfu-util version 0.1+svn
> with a current libusb-win32 driver as installed by zadig ( V220.127.116.11 ) and it
> works great (Win7 x64).
> 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?
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
> 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
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? 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
More information about the devel