My usb device draws power from external power supply, only D+ and D- is connected to BBB. It works 90% of time but when I mess around too much (on/off too frequently maybe, not confirmed), it will reset the USB of BBB and then it will behave very strangely. Every access to /sys/bus/usb take more than 15 seconds and timeout eventually.
Hope my experience gives some hint... On Mon, Oct 28, 2013 at 3:05 PM, <[email protected]> wrote: > Have you tried a quick test using a usb hub? This would completely > eliminate any issues with current drain. > > I have found some usb devices have high transient current drains which can > cause intermittent shutdowns of the USB port on the BBB. I know that you > are powering your device with an external power supply, but maybe there are > some issue with the hardware design in the device. A quick test with a hub > might be revealing? > > I have always disabled the USB runtime power management option in the > kernel. Hot-plugging still seems to work for me, providing the USB device > is connected during BBB power-up. (I am using Angstrom 2012.12 with the > latest kernel patches). Where I need hot-plugging and cannot guarantee the > device will be plugged in on power-up, then a hub must be used. I never > tried polling with readlink or equivalent. > > Regards .. > > On Monday, May 13, 2013 2:08:32 AM UTC+10, Andrew Henderson wrote: >> >> Hello all. I have been working on porting a project of mine ( >> http://www.beaglesnes.org) from the BeagleBoard-xM over to the >> BeagleBone Black. I am running a Linux kernel based on the am33x-v3.8 >> branch of Robert Nelson's linux-dev GitHub project. It is similar to the >> kernel built directly by the branch's build_kernel.sh script, but I've >> removed a number of modules, unused file systems, etc. in order to make the >> kernel a bit smaller. I use the toolchain fetched by the build_kernel.sh >> script to build the kernel. The Linux distro underneath is an Ubuntu >> Quantal 12.10 armhf. I'm using the v2013.04 u-boot release that I've built >> using an arm-cortex_a8-linux-gnueabi cross-compiler toolchain (GCC 4.4.6) >> that I built using crosstool-NG (v1.18.0). >> >> USB ERRORS: >> >> I have most of the issues worked out, but I'm still seeing some issues >> with the USB subsystem on the board. I picked back through several >> thousand messages in the Google group, but I did not see my particular >> issue addressed. I will occasionally see the BBB refuse to enumerate an >> HID gamepad plugged into the USB1 Host port with the following error: >> >> usb 1-1: device descriptor read/64, error -110 >> >> My research has shown that a 110 error refers to being unable to >> enumerate the USB device because power is exceeded. I'm not sure why this >> would be the case, since I am using a 5V power supply, rather than >> supplying power via USB. The gamepad being plugged into the Host port >> should not be drawing a lot of power. The odd thing is that the -110 error >> will occur after multiple power cycles in a row, but then disappear. At >> that point, plugging in the gamepad will work fine for several more power >> cycles (the USB device will enumerate and be properly identified). There >> doesn't seem to be any rhyme or reason to it. It doesn't matter if the >> board is hot or cold, if the reset button is pressed or not at the last >> power cycle, etc. I'll just get a string of either "working" or "not >> working" for the USB device enumeration. >> >> I have tried playing with the kernel configuration a bit to see if I >> might be able to remove this problem. I tried removing EHCI support to >> force the gamepad to be enumerated as a USB 1.1 device, since my research >> has shown that going from USB 2.0 to 1.1 will reduce power usage for some >> devices. No luck there. I also reviewed the patches currently in the >> GitHub repository, but the closest one that I could see that might effect >> this is the patch usb/0011-ARM-OMAP-am335x-musb-**use-250-for-power.patch. >> I didn't see anything in the AM3359A errata that relates to this, either. >> >> Any suggestions? Has anyone seen something similar? Are there any known >> work-arounds? >> >> HOTPLUG WORK-AROUND: >> >> Some of you might have already seen something similar to this, but I >> figure that it wouldn't hurt to share my approach on it. My application >> (BeagleSNES) supports the hotplugging of USB gamepads on the BB-xM, so I've >> added support for this in userspace in my BBB port. My review of >> the usb/0009-MUSB-Hack-around-**to-make-host-port-to-work.**patch showed >> a comment of "After removing the device, issue lsusb to cause it to scan >> the bus again." Using lsusb doesn't work for me, but "cat >> /dev/bus/usb/001/001 > /dev/null" does. If I unplug the gamepad, plug it >> back in, and then issue that shell command, an ls of "/dev/bus/usb/001" >> will show that the gamepad has been enumerated again. I do this >> programmatically in my code using the following process: >> >> 1. I perform a "cat /dev/bus/usb/001/001 > /dev/null" in the launch >> script for my app (called from rc.local) to scan the bus prior to start. >> 2. In my application, I poll once per second or so via readlink() on the >> file /dev/input/by-path/platform-**musb-hdrc.1.auto-usb-0:1:1.0-**joystick >> to see if the gamepad is plugged in. >> 3. If it is plugged in, I make a note of it, open the proper /dev/jsX >> file, and interact with the gamepad. >> 4. If the gamepad has been unplugged (i.e. readlink() fails), I do the >> following: >> >> int usbFD, usbCount; >> char buffer[1024]; >> sleep(2); /* Give the kernel time to sync up (a sync() also works >> here, but is overkill) */ >> /* Force a read of the USB bus to emulate hotplugging */ >> usbFD = open("/dev/bus/usb/001/001", O_RDONLY); >> while((usbCount = read(usbFD, buffer, 1024)) > 0); >> close(usbFD); >> >> >> 5. After this, I go back to the regular readlink() polling. If a gamepad >> poll now has a successful readlink(), a gamepad has been plugged back in. >> Open it via /dev/jsX (whatever device the readlink() points to) and >> continue on. >> >> This addresses the hotplugging issue for me, but I happen to know the >> exact USB file to look for and I know which bus to force a rescan on. >> There is also the 2 second delay that occurs when a gamepad is unplugged, >> but this is a relatively rare occurrence, so the delay is acceptable for my >> purposes (better than having no gamepad at all after it gets unplugged, >> anyway). >> >> Andrew >> >> -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to a topic in the > Google Groups "BeagleBoard" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/beagleboard/nuyyVDhU6bw/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
