Thanks Alan, So, what might be the cause for those transfers that have less data than expected? The camera works well since in my desktop PC just works with the same code compiled at the Beagle. Could it be a matter of the ARM processor clock frequency? Beagle features ARM TI AM335x at 1GHz Josep M. On Fri, Oct 19, 2018 at 6:15 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, 19 Oct 2018, Josep M. Mirats Tur wrote: > > > Hi, > > > > Thanks again for your answer. > > > > I changed to the newest Debian image available for BeagleBone boards: > > The Debian 9.5 - 4.14.71-ti-r80 > > I disabled the usb "autosuspend" by issuing the command > > echo -1 | sudo tee /sys/module/usbcore/parameters/autosuspend > > > > I cannot say if now there is data coming from the USB as I cannot > > understand the output > > But I still get errors from the driver when I check the dmesg: > > > > [ 6340.997467] usb 1-1: usbfs: usb_submit_urb returned -121 > > [ 6341.198347] usb 1-1: usbfs: usb_submit_urb returned -121 > > [ 6342.299444] usb 1-1: usbfs: usb_submit_urb returned -121 > > [ 6343.867458] usb 1-1: usbfs: usb_submit_urb returned -121 > > [ 6344.168455] usb 1-1: usbfs: usb_submit_urb returned -121 > > [ 6596.714269] musb_host_rx 1965: Rx interrupt with no errors or packet! > > [ 6596.720873] musb_host_rx 1965: Rx interrupt with no errors or packet! > > [ 6596.728656] musb_ep_program 916: broken !rx_reinit, ep2 csr 0003 > > Your program expects to transfer information from the camera in chunks > of size 20 KB, right? Those -121 errors indicate times when the amount > of data received was less than that. For example, sometimes the camera > only sent 8836 bytes, or 4228, or 14468, or 11396. At least, that's > what the BeagleBone thinks it received. > > Alan Stern > > > Let see if this info suggests you or Bin any actions to check > > Many thanks again > > Josep M. > > > > On Fri, Oct 19, 2018 at 4:24 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > > 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 > > > > > >
