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.
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…
Is the same external power supply connected to the Beagle Board?
So, the ground shield of the USB cable is connect only on one side (the device) or is it completely "floating"?
Erm… very good question. It indeed is the same external power supply connected to the Beagle Board. Or I would say all the power come from the same ATX power supply though it might (tiny little chance) be in different rails.
Frankly speaking the line was rather short (less than 5cm) so I didn’t bother to do shielding at all. The D+ and D- is using Cat5 ethernet cable.
Does it make any significance?
You issue may be there (or not).
To really really know, you can use some wide bandwidth digital oscilloscopes to see how the USB signals are behaving.
Or try to use a good shielded USB cable.
Guess what is the cheapest option, try it, and after that please tell us what did you find.
Erm, ok. I’ll look for a good shielded cable…
Hi，I have the same issue with musb babble interupt. some low speed mouse can enumerate
normally on my box, some mouse will always fail.
For the failed mouse, there is always a babble interrupt, and the host mode lost(DEVCTL is 0x98).
But I can work around with a externsion cord(about 1.5m), all the failed mouse can work in
Could you give me some hint for debugging this problem? I think it may be the bug with mentor’s
I haven’t got time to touch BBB recently. Most of my time devote to testing of some other device. Frankly speaking BBB more or less having the least stable USB with 3.8 kernel. There was a patch in this thread indeed helped somehow but still it gives trouble when it want.
From the first day we understand the USB is quite sensitive to current draw or whatever, we have been using separate power from day 1 and have tested using extension cord of more than 10m which didn’t really cause much difference IMHO. Sorry not able to provide much useful information, will definitely revisit here when I got time to play with BBB again.
Meanwhile set mpurate indeed helped quite much with the old kernel. But since the USB patch from kernel, I don’t feel any substential difference by applying it and what’s more it seems sometimes ignore my setting >_<.