Re: [Libusbx-devel] libusb_control_transfer() stalls

[Pete B. <pe...@ak...>]

Hi Markus,

On 2012.06.12 15:32, Markus wrote:
> I'd like to replace a vendor tool for firmware download
> to a developement board by using libusbx.

OK.

> As of now, I can read and write memory by using vendor request
> control transfers. According to the manufacturer this is the way
> to go for firmware dump and download.
>
> wValue (LSW) and wIndex (MSW) make up the address offset to write
> the data to within device memory.
>
> In both cases (r/w), the maximum value for wValue is 0x4000, after
> that libusb_control_transfer() returns pipe errors. As it is
> possible with the original tool to write beyond this address, I
> suspect it's not the device that produces the stall.
>
> Do you see a possibility that it originates from libusbx or
> should I concentrate on the driver (which is WinUSB installed by
> the latest libusbK driver wizard)?

Provided you run Windows 7, and considering that you have an original 
app that you are trying to duplicate, the first thing I'd try would be 
to use NetMon's USB stack, or an USB analyzer if you have access to one, 
and see if you can identify differences between what the 2 apps send on 
the bus. Hopefully there's something easy to spot that can give you a 
clue as to why the stall occurs and which of the hardware or 
software/library needs to be investigated next.

If you need info on setting up netmon for USB snooping, you can have a 
look at [1].

> As I don't have any known-good device where I could meaningfully
> test a control transfer with wValue>  0x4000, I'd also be happy
> for any hint towards how to reproduce this behaviour.

Does the original firmware flashing app use a specific driver?

There are cases that I know of where the WinUSB driver/DLL can modify 
some of the attributes provided. Basically, when using interface control 
requests (LIBUSB_RECIPIENT_INTERFACE), WinUSB may override the low byte 
of wIndex with the destination interface. However, this behaviour is 
limited to interface requests, where it makes sense, and vendor 
operations tend to use LIBUSB_RECIPIENT_DEVICE where no such 
restrictions apply.

Regards,

/Pete

[1] http://pete.akeo.ie/2011/03/troubleshooting-usb-device-development.html