dfu-util on windows with libusb-1.0

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

_______________________________________________
devel mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: dfu-util on windows with libusb-1.0

Andrew Leech
On 4/06/12 11: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?


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 <a class="moz-txt-link-freetext" href="git://git.libusb.org/libusb-pbatard.git">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


_______________________________________________
devel mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/devel

libusb-pbatard_K_libusbk_fn_names_patch (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: dfu-util on windows with libusb-1.0

Tormod Volden
In reply to this post by Andrew Leech
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.
> 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?

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?

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

>
> Thanks,
> Andrew

_______________________________________________
devel mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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

_______________________________________________
devel mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/devel
Loading...