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
devel@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/devel
