dfu-util on windows with libusb-1.0

[Andrew Leech]

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.
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 ( V1.2.5.0 )
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?

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,
Andrew

[Andrew Leech]

Post by Andrew Leech
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?
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.

Hi,
To follow up on my previous post, I've got a new git compile working
with libusbk.sys and the (unsupported) libusb-pbatard K branch:

$ git clone git://git.libusb.org/libusb-pbatard.git -b K

and a patch to fix the libusbk export names (attached); in
libusb-pbatard the libusbk functions all have a capital 'L' in front of
them, must be from an old version of libusbk.
I found it useful to use "./configure --disable-shared" to ensure I
din't have any dll dependencies hiding in the compiled libs.

I installed libusbk.sys vers 3.0.5.13 from
http://sourceforge.net/projects/libusbk/files/
and compiled dfu-util unmodified but linked against the custom libusb:

$ USB_CFLAGS="-I../../libusb-pbatard/libusb/"
USB_LIBS="-L../../libusb-pbatard/libusb/.libs/ -lusb-1.0" ./configure
--host=i586-mingw32msvc

I initially cross compiled on linux (hence the --host=i586-mingw32msvc
above), but as an exercise I've also compiled it with mingw/msys on
windows. I had to install pkg-config to make configure work, it ignores
the USB_CFLAGS/USB_LIBS without it.
I had previously tried to compile with cygwin/mingw (with CC="gcc
-mno-cygwin") but had lots of problems with trying to statically link
libpthreads required by libusb and eventually gave up. The libraries
included in mingw/msys seemed to work without any setup.

I've also been able to compile it under ms visual c, but had to add a
seperate getopt library and find a couple of header files not supplied
by msvc. It got a bit messy in the end, if I get a chance I'll clean
that up and post my changes. I may end up re-writing some of the code to
allow use from a dll rather than a standalone exe, but that will depend
on project requirements at works end and looking into the gnu aspects a
bit closer.

Hopefully in a few months libusbx will have libusbk.sys / libusb0.sys
support and I'll be able to compile against a supported library rather
than Pete Batard's old libusb-1 repo, considering he's one of the
primary libusbx developers.

Cheers,
Andrew

[Tormod Volden]

Post by Andrew Leech
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.
My device is predominantly used on windows, but I've had reliability isuues
with the dfu software that's supplied by NXP.
   $ ../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 ( V1.2.5.0 ) 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?

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?

Post by Andrew Leech
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? 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

Post by Andrew Leech
Thanks,
Andrew

[Andrew Leech]

Post by Tormod Volden

Post by Andrew Leech
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.

Post by Tormod Volden

Post by Andrew Leech
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.

Post by Tormod Volden
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