On Fri, 19 Oct 2018, Josep M. Mirats Tur wrote: > Hi Stern, > > > First question: Does you get similar failures if you plug the device > > into a standard PC rather than the BeagleBone? > > > > No, I checked with my desktop PC running Ubuntu 14.04 and it perfectly > works (using exactly the same code I compile in the Beagle) > > > Second question: Have you tried looking at usbmon traces to see where > > the communication starts to fail? > > > > II tried now, I'm attaching the trace I get, which I cannot understand The usbmon trace shows a few errors in the musb-hdrc driver. Here are the relevant parts: dcf40b00 1096317503 S Ci:1:001:0 s a3 00 0000 0001 0004 4 < dcf40b00 1096317572 C Ci:1:001:0 0 4 = 05010100 This shows the system polling the root-hub port status. The return value indicates that the camera was just plugged into the port, but it also shows that the port is suspended, which makes no sense. The suspend bit remains set in later port-status queries. dcf39600 1096487577 S Co:1:001:0 s 23 03 0004 0001 0000 0 dcf39600 1096487621 C Co:1:001:0 0 0 dce0ac80 1096537473 C Ii:1:001:1 0:2048 1 = 02 dce0ac80 1096537498 S Ii:1:001:1 -115:2048 4 < dcf39600 1096547461 S Ci:1:001:0 s a3 00 0000 0001 0004 4 < dcf39600 1096547507 C Ci:1:001:0 0 4 = 07051200 The shows the system telling the root hub to reset port 1. When the reset is finished, the status shows a reset-status change (which is correct) together with an enable-status change (which is wrong). (It also still shows that the port is suspended!) dcfc0b00 1096767206 S Ci:1:001:0 s a3 00 0000 0001 0004 4 < dcfc0b00 1096767285 C Ci:1:001:0 0 4 = 07050200 Following the enumeration of the USB camera, the system again checks the port status. The value shows an enable-status change, which is supposed to mean that the port has been disabled. But the port has not been disabled, as we can see from the fact that the enable-status bit is also set. The trace ends at this point. It does not show any communication failures like what you described in the original email message. > > > Should I load different usb modules in the system kernel? Should I > > > modify a given module? > > > > It certainly looks like a problem in the musb-hdrc driver. You might > > try asking the maintainer for that driver. > > Ok, could you please provide me the e-mail address where to write? The maintainer is Bin Liu (CC'ed). And you should also remember to CC the linux-usb mailing list. Alan Stern > Thanks > > > On Thu, Oct 18, 2018 at 9:44 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > > On Thu, 18 Oct 2018, Josep M. Mirats Tur wrote: > > > > > Hi > > > > > > I've recently acquired a BeagleBone Green with AM335x processor. I 'm > > > connecting a USB device (actually a 3D camera from ORBBEC) to the > > > Beagle USB host port. It recognizes well as I can see at the dmesg > > > output: > > > > > > [12411.643517] usb 1-1: new high-speed USB device number 2 using musb-hdrc > > > [12411.784848] usb 1-1: New USB device found, idVendor=2bc5, idProduct=0404 > > > [12411.784912] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 > > > [12411.784951] usb 1-1: Product: ORBBEC Depth Sensor > > > [12411.784986] usb 1-1: Manufacturer: Orbbec(R) > > > > > > However, when I try to read data from the camera using the OpenNi SDK > > > that ORBBEC provides for Arm devices, although I can connect to the > > > camera (in fact it toggles on the IR) I get a timeout and get no data > > > ever. The 'dmesg' output show the errors: > > > > > > [12446.755020] usb 1-1: usbfs: usb_submit_urb returned -121 > > > > > > Other users seemed to have this problem in the past, and it seems > > > related to the EHCI driver itself, > > > > The log message above indicates that the BeagleBone's USB host > > controller uses the musb-hdrc driver. This means it is not EHCI. > > > > > but I've not been able to find a > > > solution and need help urgently to solve this issue. > > > > > > The system version in my BeagleBoneGreen is Debian Debian 8.3 > > > (4.1.15-ti-rt-r43). In fact I've tested several versions including the > > > newest one available for BeagleBone (the debian 9.5 - 4.14.71-ti-r80), > > > but without success. In this case I got a different error from dmesg: > > > > > > Oct 17 16:59:29 arm kernel: [ 215.611056] musb_host_rx 1965: Rx > > > interrupt with no errors or packet! > > > Oct 17 16:59:29 arm kernel: [ 215.617649] musb_host_rx 1965: Rx > > > interrupt with no errors or packet! > > > Oct 17 16:59:29 arm kernel: [ 215.625557] musb_ep_program 916: broken > > > !rx_reinit, ep2 csr 0003 > > > > > > > > > Please I need some clues about this. > > > > First question: Does you get similar failures if you plug the device > > into a standard PC rather than the BeagleBone? > > > > Second question: Have you tried looking at usbmon traces to see where > > the communication starts to fail? > > > > > Should I load different usb modules in the system kernel? Should I > > > modify a given module? > > > > It certainly looks like a problem in the musb-hdrc driver. You might > > try asking the maintainer for that driver. > > > > Alan Stern
