usbboot/libusb cannot parse endpoints on windows 7

[saltpotato]

Hy,

I cannot really explain the cause.

On some machines with windows 7 rpiboot fails. Windows 10 works in my particular instance.

Here the output from "rpiboot -v"

Found device 4 idVendor=0x04f2 idProduct=0xb51c
Bus: 1, Device: 5 Path: 1-9
Found device 5 idVendor=0x0a5c idProduct=0x2764
Bus: 1, Device: 19 Path: 1-1.3
Device located successfully
libusb: error [parse_endpoint] invalid extra ep desc len (0)
libusb: error [raw_desc_to_config] parse_configuration failed with error -1
libusb: warning [winusbx_claim_interface] auto-claimed interface 0 (required to
claim 1 with WinUSB)
Failed to claim interface

In the above log-messages, the messages prefixed by "libusb:" are showing that the endpoint cannot be parsed and thus cannot send bootcode.bin.

Ignoring the error (compile by vs-2012) does not help.

I could be a driver issue, but it could also be solved by the app. I dont know, a direction would be appreciated.

(I am not a driver expert and looking into libusb is a bit ... on most machines i obeserved, it does work)

i have also a usb-tree good-bad diff...

From the usb-treeview on both machines, left side results in good cmboot, right side bad -.

Observations from the diff: -configuration desriptor has more data bigger ( bad has 0x55, good 0x32 ) -bad reports eventually a empty interface as third interface -good has appearantly a out/out interface, bad has out/in, bad might be the winner here -endpoint adresses are not the same (at least meant for the out endpoint), even...

Maybe this might be interesting because some machines dont work. -and they all got usb3 only ( intel usb 3.0 extensible Hostcontroller )

I know this is very specific and is not really an issue of rpiboot itself.

Thanks Martin

-update It might also be a libusb issue, since i wrote myself an example only using winusb (https://github.com/madwizard-thomas/winusbnet)

and this one works always finding the endpoints (see txt, its a c# program, converted from usbboot/main.c)

rpiboot.txt

[ghollingworth]

What x86 hardware is this? I think this is possibly a problem with the Windows PC hardware complaining about a response being too long. This is a known issue and thought only to effect Macs, but it's possible it's not limited to the Mac

[saltpotato]

runnig dx-diag and display-related sections removed... DxDiag.txt

Or which specific infos would you like to see about usb-controller?

its a too long descriptor seen from usb-tree (probably usb-tree is not displaying it correctly) effectively libusb scans the last endpoint (ep) as being too short. It needs the ep being of minimum length of two bytes libusb\descriptor.c and search for "invalid extra ep desc len (%d)" (v.1.0.19 or master) -not a problem from libusb appearantly, because windows-10 works, probably beneath, winusb maybe or how cm3 responds

Actually libusb is a lot of code and you get lost in the call-stack, so a lot of indexing ops result in being to short...

as i see from a german forum someone solved the issue by plug/unplug usb quickly. i could not yet reproduce... https://revolution.kunbus.de/forum/viewtopic.php?f=8&t=186&start=50

(cut paste google translate for en)

[ghollingworth]

Not sure what it is that is wrong in this, I'd really need to run the USB analyser in the failing case to understand what is different...

Is this only on a specific Windows 7 computer? Does it happen with all compute modules or just this one in particular...

Gordon

[ghollingworth]

Closing assuming it is the same problem as seen on a small number of Mac machines (assuming they share the same USB root hub hardware.