Reading device issues using libusb

Question

The situation is this: I have a USB device (a custom device I'm trying to talk to) with two endpoints, one write to the device, one read from the device. Both are mass transmissions. Each communication transaction takes the form (1) Write a command to a device (2) Read the answer. I use libusb (version 0.1, not 1.0 beta) to actually execute messages.

Everything is fine on Windows. I can connect the device, request an interface and communicate with pleasure. However, in Ubuntu (the default Hardy installation for the desktop), while I can connect to and write to the device, all read operations fail with the error message "Error sending URB: invalid argument" from the libusb file (error code is 22).

If I check / var / log / messages, I see a warning message registered at the same time as when I tried to read: "sysfs: duplicate filename" usbdev4.3_ep81 "could not be created" - this matches the device (this is really on this bus, and this is the endpoint 81 I'm trying to read about).

So ... has anyone seen a similar problem with libusb or any idea how to fix it?

Answer 1

It turns out that it was the wrong configuration in the descriptors of the device itself. lsusb -v showed an additional interface that was never used, which had a single 0x81 isochronous endpoint. Since it was never used (and it was never checked as far as I could see, so it might not have been correctly defined), I completely deleted it from the device descriptors (in the firmware).

And now I have a fully working device. Why Linux refused to read from the device, but Windows worked fine, I don’t know, but it definitely sent me to wild hunt for geese.

Answer 2

I have not used libusb after some time, but the sysfs error indicates that this is more of a kernel problem rather than libusb, so I would start trying to track it. (You should not try to work with libusb until you are sure that your kernel is talking correctly to the device).

Is the patch on http://kerneltrap.org/mailarchive/linux-usb-devel/2007/10/17/345922 is applicable to your kernel? (If so, fix the problem?)

Answer 3

I needed to hack udev rules in order to get a device created with the correct permissions for libusb to work. For instance:

SUBSYSTEM=="usb" ATTRS{idVendor}=="0a81", ATTRS{idProduct}=="0701", \ MODE="0666" SYMLINK+="missile_launcher" 

(It was a usb rocket launcher in which I wrote the driver.

Also, this fragment should not have collided with the core.

 if(LIBUSB_HAS_DETACH_KERNEL_DRIVER_NP) { // Detach kernel driver (usbhid) from device interface. (Linux hack) usb_detach_kernel_driver_np(launcher, 0); usb_detach_kernel_driver_np(launcher, 1); } 

I'm not sure how this relates to your problem, but at least there are two possible points of failure that may be involved.

Answer 4

You can try WinDriver is a commercial tool, but have a free full functional evaluation (somehow limited time). You can check using WinDriver, and if the problem is reproduced, it could be a device error or your protocol. You did not provide sufficient information to determine or analyze.