Yes, one hardware is xum1541 with opencbm. The other hardware is a Saleae logic analyzer with a Cypress CY7C68013, running pulseview or sicrok-cli. The latter is the one with the logs attached in the main post. I have no possibility to check with a protocol analyzer though. But I have tried many patches for opencbm, and none have solved the problem.
64-bit libusb LIBUSB_TRANSFER_TIMED_OUT after closing and reopening connection in higher speeds
95% of the time, while using higher speeds (~ >=10Mbps) and connection is closed, the subsequent runs fails with LIBUSB_TRANSFER_TIMED_OUT, until it is run once in lower speed. This does not occur in 32-bit. The problem exists for Arch 64bit, Ubuntu 64bit, and even Windows 64bit at some extent. sigrok-cli, pulseview, and opencbm is affected, as I know of. Attaching some logs from sigrok-cli (1Mbit and 12Mbit runs) http://sprunge.us/ZfEE mirror: http://ix.io/Dvi
- 点赞 评论 复制链接分享
Or under Linux, you can capture the kernel usbmon log to see what is going wrong. https://www.kernel.org/doc/Documentation/usb/usbmon.txt点赞 评论 复制链接分享
Based on the symptom, it is very unlikely a libusb issue. usbmon log may help to see if the device itself or maybe the kernel is the problem. And if it is really a libusb problem, the log may provide some hints.点赞 评论 复制链接分享
I will try to capture with usbmon some day ahead. It will have to wait a while though, as I don't have time to fiddle with my kernel now.点赞 评论 复制链接分享
Any update? I would like to close out this issue if there is nothing further to add.点赞 评论 复制链接分享
Yes. I took the time yesterday to investigate further. Here is a usbmon dump from when I run pulseview capture 1MHz, 24MHz, and then 1MHz again. I have also found that other people have the exact same issue ( https://www.reddit.com/r/archlinux/comments/5fz6h6/libusb_timeouts_with_fx2lafw_logic_analyser_and/ ) usbmon dump: http://sprunge.us/KCIB mirror: http://ix.io/Dum点赞 评论 复制链接分享
And here is a usbmon dump when xum1541 finalizes, and the subsequent run fails. http://sprunge.us/hPje mirror: http://ix.io/Dud I dont understand the logs, but I hope they are helping, and I will collect more if you ask me to. :)点赞 评论 复制链接分享
Which API is being used here, sync or async? What I'm seeing from the usbmon trace is batches of 32 URBs being submitted, followed by a control transfer (to start the data flow?). When the first URB completes, the remaining 31 are being discarded in reverse order of submission. In general, the second URB submitted, which is the last to be discarded, has some amount of data already received from the device.
I also see that the transfer length is either 10,240 or 240,128 bytes. I'm guessing this has to do with the speed at which the device is operating, the larger transfer length being for the higher speed. For the first batch of URBs of the larger transfer length, I see that the behavior described above--the first one completes successfully and the remaining are discarded in reverse order of submission. In particular, the first URB completes about 10ms after the control transfer is sent to the device. For the next batch of URBs, the device does not send any data to the host after the control transfer. After about 400ms, the entire batch of URBs is discarded and then 32 new ones are submitted. This process repeats several times, but I do not see any control transfers in between these discard/submission cycles. Also, it looks like discarding and submission is interleaved, so userspace must not be serializing this operation.
It is unclear from this log why the device is not sending data back to the host after the first batch of URBs. Is the device sensitive to FIFO overruns? Having many outstanding URBs queued is great for ensuring the device is best able to deliver data as it is ready to send, but the process of unlinking all the URBs (especially the second one which is being filled as it is being discarded) may cause some FIFO overrun to occur if the device is ready to send data but the host controller isn't asking for any. The behavior of the application is rather odd in how it is managing transfers to the device. Why do all the remaining transfers need to be canceled once the first completes?点赞 评论 复制链接分享
I have talked to opencbm developer a bit more about this, and tried some rewrite of the code. But it didn't work. I installed the same distro on a laptop (usb 2 though), and it worked there. This is maybe some issue with some usb-controllers and libusb and/or kernel driver. Everything else works as expected, mice, keyboard, usb-sticks, card-readers, cams, etc.
The board I am using now is MSI Z77A-GD55 with Intel® Z77 Chipset.
I have ordered a new PCIe-USB3, and will try it when it arrives.点赞 评论 复制链接分享
New PCI->USB didn't help. :/ The problem still persists.点赞 评论 复制链接分享
All in all, I do not think this is a libusb issue. Rather you may want to check the kernel. You may want to check your distro for support.点赞 评论 复制链接分享
No further information, so closing this. The OP can reopen if there is additional information to provide.点赞 评论 复制链接分享
This sounds strange that there is a difference between 32bit and 64bit libusb. Usually the above comes from Device HW/FW problem (one run okay and the next run failed).点赞 评论 复制链接分享
- weixin_39783156 4月前
The device in question is a xum1541 running on an Arduino Pro Micro (Atmega 32u4). I can confirm that this is not happening on 32 bit systems for some reason. I find it difficult to imagine it's a hw/fw fault if it only affects 64 bit systems. More likely some kind of compatibility issue, which in that case is on the computer and not on the device.点赞 评论 复制链接分享
It will be good to use a USB HW Protocol Analyzer to look at the issue from the low level. Sometimes it is related to Data Toggle issues.点赞 评论 复制链接分享