USB errors (and hotplug work-around)

[Shi Bai]

Hi Andrew,

Did you manage to get any progress on this issue?

I'm having very similar issue when testing with Huawei LTE modem. The
system is very reluctant to recognize the Modem. I tried to reset the usb
root hub by following script and it managed to find a USB hub attached to
it but regularly giving eror: usb 1-1: khubd timed out on ep0in len=0/64
and the -110 error.

#!/bin/bash
echo '0' | sudo tee /sys/bus/usb/devices/usb1/authorized
sleep 2
echo '1' | sudo tee /sys/bus/usb/devices/usb1/authorized
sleep 2
echo 'on' | sudo tee /sys/bus/usb/devices/usb1/power/control

I applied your fix for mpurate and it seems to have much less error and the
-110 error is gone, remains the ep0in len=0/64

I just upgraded the kernel and all firmwares (include all dts files) to
Robert's latest kernel 3.8.13-bone20 and the modem seems working somehow.

I will post any update if I can prove it to be stable.

Regards,
Bai Shi

I have some further information. I have been examining a number of system
logs for times that USB has worked and times that I have received the -110
error. This has allowed me to isolate two items of interest in the logs.
1. In the complete log that I posted where the -110 error occurs, this
[ 0.133639] vdd_mpu: 925 <--> 1325 mV at 1100 mV
[ 0.XXXXXX] vdd_mpu: 925 <--> 1325 mV at 1325 mV
This is consistent. If it will fail, it is 1100 mV. If it works, it is
1325 mV.
[ 2.034721] CAUTION: musb: Babble Interrupt Occurred
This event never occurs in the logs where the error does not occur.
Looking KERNEL/arch/arm/boot/dts/am335x-boneblack.dts, I see that vdd_mpu
must be the operating-points for "cpu". If the CPU is clocked at 600 MHz,
the voltage is 1.112 mV. If it is 1GHz, the voltage is 1.325. I was
surprised to see that the vdd_mpu appeared to be bouncing up and down like
that. I added the kernel command line option of "mpurate=1000" to uEnv.txt
for u-boot, which always changes the vdd_mpu to 1.325 mV. While I was
hoping that this would also fix the "Babble Interrupt Occurred", that is
not the case. I still observe that happening. On the bright side, I
appear to be getting the babble interrupt and -110 errors far less now that
I added mpurate=1000 to the kernel command line.
If anyone has any ideas, I'm all ears.
Andrew

[Andrew Henderson]

Post by Shi Bai
Hi Andrew,
Did you manage to get any progress on this issue?
I'm having very similar issue when testing with Huawei LTE modem. The
system is very reluctant to recognize the Modem. I tried to reset the usb
root hub by following script and it managed to find a USB hub attached to
it but regularly giving eror: usb 1-1: khubd timed out on ep0in len=0/64
and the -110 error.
#!/bin/bash
echo '0' | sudo tee /sys/bus/usb/devices/usb1/authorized
sleep 2
echo '1' | sudo tee /sys/bus/usb/devices/usb1/authorized
sleep 2
echo 'on' | sudo tee /sys/bus/usb/devices/usb1/power/control
I applied your fix for mpurate and it seems to have much less error and
the -110 error is gone, remains the ep0in len=0/64
I just upgraded the kernel and all firmwares (include all dts files) to
Robert's latest kernel 3.8.13-bone20 and the modem seems working somehow.
I will post any update if I can prove it to be stable.

I believe that this patch addresses the -110 error by resetting the USB
host interface upon a USB babble interrupt:
http://permalink.gmane.org/gmane.linux.kernel/1498448

I've verified that this patch fixes the hotplugging issue from the kernel
side (so no need to cat out the USB bus from userspace anymore):
https://github.com/RobertCNelson/linux-dev/blob/am33x-v3.8/patches/usb/0013-usb-musb-avoid-stopping-the-session-in-host-mode.patch

Andrew

[Shi Bai]

Hi Andrew,

Thank you so much for your detailed answer. It indeed addressed my doubts
very well. I believe my Huawei modem is triggering babble interrupt in the
initializing stage and seems not only my device, but some other device will
trigger it as well. The hot plug fix looks very promising as well. I
haven't had a single hot plug issue since the upgrading.

May I ask if you have idea now why the mpurate will reduce the -110 error?

Regards,
Bai Shi

Post by Andrew Henderson

Post by Shi Bai
Hi Andrew,
Did you manage to get any progress on this issue?
I'm having very similar issue when testing with Huawei LTE modem. The
system is very reluctant to recognize the Modem. I tried to reset the usb
root hub by following script and it managed to find a USB hub attached to
it but regularly giving eror: usb 1-1: khubd timed out on ep0in len=0/64
and the -110 error.
#!/bin/bash
echo '0' | sudo tee /sys/bus/usb/devices/usb1/authorized
sleep 2
echo '1' | sudo tee /sys/bus/usb/devices/usb1/authorized
sleep 2
echo 'on' | sudo tee /sys/bus/usb/devices/usb1/power/control
I applied your fix for mpurate and it seems to have much less error and
the -110 error is gone, remains the ep0in len=0/64
I just upgraded the kernel and all firmwares (include all dts files) to
Robert's latest kernel 3.8.13-bone20 and the modem seems working somehow.
I will post any update if I can prove it to be stable.

I believe that this patch addresses the -110 error by resetting the USB
http://permalink.gmane.org/gmane.linux.kernel/1498448
I've verified that this patch fixes the hotplugging issue from the kernel
https://github.com/RobertCNelson/linux-dev/blob/am33x-v3.8/patches/usb/0013-usb-musb-avoid-stopping-the-session-in-host-mode.patch
Andrew

[Andrew Henderson]

Post by Shi Bai
Hi Andrew,
Thank you so much for your detailed answer. It indeed addressed my doubts
very well. I believe my Huawei modem is triggering babble interrupt in the
initializing stage and seems not only my device, but some other device will
trigger it as well. The hot plug fix looks very promising as well. I
haven't had a single hot plug issue since the upgrading.
May I ask if you have idea now why the mpurate will reduce the -110 error?

Babble interrupts are caused by a noisy signal ("babbling") occurring on
the USB signal line. The typical causes for this that I have observed are
improper grounding and static electricity. My guess is that by increasing
the mpurate, which increases the core MPU voltage, you increase the voltage
of the USB signal and make it a little bit more tolerant to the conditions
that cause a babble interrupt. My testing of the babble recovery patch has
shown me that it isn't perfect. It will recover from the babble interrupt
once, but then hotplugging will not work. Some examples:

1. The USB device is plugged in at boot, and a babble interrupt occurs.
The device will work until it is unplugged. When plugged back in, it is
not recognized.
2. The USB device is plugged in at boot, and no babble interrupt occurs.
The device will work until it is unplugged. When plugged back in, it is
recognized and is reinitialized and begins working again.

I think that investigating BBB grounding issues might be the best way to go
to ultimately address these babble interrupt issues.

Andrew

[Gerald Coley]

You definitely need to ground the board properly. A grounded supply is the
best but make sure it is the same ground/power strip as the PC or monitor
that you may be connected to.

Gerald

Post by Andrew Henderson

Post by Shi Bai
Hi Andrew,
Thank you so much for your detailed answer. It indeed addressed my doubts
very well. I believe my Huawei modem is triggering babble interrupt in the
initializing stage and seems not only my device, but some other device will
trigger it as well. The hot plug fix looks very promising as well. I
haven't had a single hot plug issue since the upgrading.
May I ask if you have idea now why the mpurate will reduce the -110 error?

Babble interrupts are caused by a noisy signal ("babbling") occurring on
the USB signal line. The typical causes for this that I have observed are
improper grounding and static electricity. My guess is that by increasing
the mpurate, which increases the core MPU voltage, you increase the voltage
of the USB signal and make it a little bit more tolerant to the conditions
that cause a babble interrupt. My testing of the babble recovery patch has
shown me that it isn't perfect. It will recover from the babble interrupt
1. The USB device is plugged in at boot, and a babble interrupt occurs.
The device will work until it is unplugged. When plugged back in, it is
not recognized.
2. The USB device is plugged in at boot, and no babble interrupt occurs.
The device will work until it is unplugged. When plugged back in, it is
recognized and is reinitialized and begins working again.
I think that investigating BBB grounding issues might be the best way to
go to ultimately address these babble interrupt issues.
Andrew
--
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
For more options, visit https://groups.google.com/groups/opt_out.

--
Gerald

gerald-hcmAuCOw+vXj4SYmN/***@public.gmane.org
g-coley1-***@public.gmane.org
http://beagleboard.org/
http://circuitco.com/support/

[Juanjo]

Gerald,

You mean a 5VDC adapter which negative is grounded ?

These are dificult to find, at least most of those adapters have only two
connectors for the outlet :(

OTH. Are there any testpoints for USB D+ and D- on the BBB so I can patch
my oscilloscope ?

I'm having lots of errors with USB 3G modems (mostly Huawei) and would like
to see the eye pattern if posible. My error aren't Babble Interrupts but
more like (and reported by others too):

[20589.786521] WARNING: at drivers/usb/musb/musb_host.c:125
musb_h_tx_flush_fifo+0x54/0x88()
[20589.795094] Could not flush host TX2 fifo: csr: 2103

Post by Gerald Coley
You definitely need to ground the board properly. A grounded supply is the
best but make sure it is the same ground/power strip as the PC or monitor
that you may be connected to.
Gerald

Post by Andrew Henderson

Post by Shi Bai
Hi Andrew,
Thank you so much for your detailed answer. It indeed addressed my
doubts very well. I believe my Huawei modem is triggering babble interrupt
in the initializing stage and seems not only my device, but some other
device will trigger it as well. The hot plug fix looks very promising as
well. I haven't had a single hot plug issue since the upgrading.
May I ask if you have idea now why the mpurate will reduce the -110 error?

Babble interrupts are caused by a noisy signal ("babbling") occurring on
the USB signal line. The typical causes for this that I have observed are
improper grounding and static electricity. My guess is that by increasing
the mpurate, which increases the core MPU voltage, you increase the voltage
of the USB signal and make it a little bit more tolerant to the conditions
that cause a babble interrupt. My testing of the babble recovery patch has
shown me that it isn't perfect. It will recover from the babble interrupt
1. The USB device is plugged in at boot, and a babble interrupt occurs.
The device will work until it is unplugged. When plugged back in, it is
not recognized.
2. The USB device is plugged in at boot, and no babble interrupt occurs.
The device will work until it is unplugged. When plugged back in, it is
recognized and is reinitialized and begins working again.
I think that investigating BBB grounding issues might be the best way to
go to ultimately address these babble interrupt issues.
Andrew
--
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
For more options, visit https://groups.google.com/groups/opt_out.

--
Gerald
http://beagleboard.org/
http://circuitco.com/support/

[Ulf Samuelsson]

If the "mpurate" affects the voltage, is it not then appropriate to keep
the voltage high regardless of "mpurate"
as a CONFIG to the kernel?

[g***@public.gmane.org]

Hi,

Another possible USB workaround for 3.8.13 kernel

echo on > /sys/devices/ocp.3/47400000.usb/power/control


then I can unplug and replug USB devices any time without problems.

[Bai Shi]

To be it works many times, but once upon a time it will refuse to work and
all call to /sys/devices control will take long time before timeout. It
happens quite randomly and I couldn't capture a pattern when it is going
wrong.

Post by g***@public.gmane.org
Hi,
Another possible USB workaround for 3.8.13 kernel
echo on > /sys/devices/ocp.3/47400000.usb/power/control
then I can unplug and replug USB devices any time without problems.
--
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
For more options, visit https://groups.google.com/groups/opt_out.

[Andrea Pola]

Some news about stable fix on hotplug in 3.8.13?

Post by g***@public.gmane.org
Hi,
Another possible USB workaround for 3.8.13 kernel
echo on > /sys/devices/ocp.3/47400000.usb/power/control
then I can unplug and replug USB devices any time without problems.

[r***@public.gmane.org]

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 ..

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).
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
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?
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
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
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

[Bai Shi]

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...

Post by r***@public.gmane.org
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 ..

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).
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
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?
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
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
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
For more options, visit https://groups.google.com/groups/opt_out.

[Paulo Ferreira]

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"?

Best regards

Paulo Ferreira

[Bai Shi]

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?

Regards,
Bai Shi

Post by Bai Shi

Post by Bai Shi
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.

Post by Bai Shi
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"?
Best regards
Paulo Ferreira
--
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
For more options, visit https://groups.google.com/groups/opt_out.

[Paulo Ferreira]

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.

Best regards
Paulo Ferreira

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?
Regards,
Bai Shi

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"?
Best regards
Paulo Ferreira
--
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.
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.
For more options, visit https://groups.google.com/groups/opt_out.

[Bai Shi]

Erm, ok. I'll look for a good shielded cable..

Post by Paulo Ferreira
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.
Best regards
Paulo Ferreira

Post by Bai Shi
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.

Post by Bai Shi
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.

Post by Bai Shi
Does it make any significance?
Regards,
Bai Shi

Post by Bai Shi
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.

Post by Bai Shi

Post by Bai Shi
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"?

Post by Bai Shi
Best regards
Paulo Ferreira
--
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.

Post by Bai Shi
To unsubscribe from this topic, visit

https://groups.google.com/d/topic/beagleboard/nuyyVDhU6bw/unsubscribe.

Post by Bai Shi
To unsubscribe from this group and all its topics, send an email to
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.

Post by Bai Shi
To unsubscribe from this group and stop receiving emails from it, send
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 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
For more options, visit https://groups.google.com/groups/opt_out.

[s***@public.gmane.org]

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
this case.
Could you give me some hint for debugging this problem? I think it may be
the bug with mentor's
USB ip.

Post by Bai Shi
Erm, ok. I'll look for a good shielded cable..

Post by Paulo Ferreira
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.
Best regards
Paulo Ferreira

Post by Bai Shi
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.

Post by Bai Shi
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.

Post by Bai Shi
Does it make any significance?
Regards,
Bai Shi

Post by Bai Shi
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.

Post by Bai Shi

Post by Bai Shi
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"?

Post by Bai Shi
Best regards
Paulo Ferreira
--
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.

Post by Bai Shi
To unsubscribe from this topic, visit

https://groups.google.com/d/topic/beagleboard/nuyyVDhU6bw/unsubscribe.

Post by Bai Shi
To unsubscribe from this group and all its topics, send an email to
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.

Post by Bai Shi
To unsubscribe from this group and stop receiving emails from it, send
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 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
For more options, visit https://groups.google.com/groups/opt_out.

[Bai Shi]

Hi Sword,

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 >_<.

Regards,
Bai Shi

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
this case.
Could you give me some hint for debugging this problem? I think it may be
the bug with mentor's
USB ip.

Post by Bai Shi
Erm, ok. I'll look for a good shielded cable..

Post by Paulo Ferreira
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.
Best regards
Paulo Ferreira

Post by Bai Shi
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.

Post by Bai Shi
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.

Post by Bai Shi
Does it make any significance?
Regards,
Bai Shi

Post by Bai Shi
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.

Post by Bai Shi

Post by Bai Shi
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"?

Post by Bai Shi
Best regards
Paulo Ferreira
--
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.

Post by Bai Shi
To unsubscribe from this topic, visit https://groups.google.com/d/

topic/beagleboard/nuyyVDhU6bw/unsubscribe.

Post by Bai Shi
To unsubscribe from this group and all its topics, send an email to
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.

Post by Bai Shi
To unsubscribe from this group and stop receiving emails from it, send
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 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
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 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
For more options, visit https://groups.google.com/groups/opt_out.

[Giuseppe Ventura]

There is a solution for Usb hotplug issue?

thanks

Il giorno domenica 12 maggio 2013 18:08:32 UTC+2, Andrew Henderson ha

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).
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
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?
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
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
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

[Ulf Samuelsson]

The USB host driver is broken.
Have offered TI to fix it for a fee, (estimate that it is going to take me
about two days),
but they plan to do it themselves so if you are patient, wait for 2.6.13
where it hopefully will be included.

[Giuseppe Ventura]

Hi,

what you mean for 2.6.13?
Are you on IRC channel of beagle?

thanks


Il giorno domenica 10 novembre 2013 17:56:15 UTC+1, Ulf Samuelsson ha

Post by Ulf Samuelsson
The USB host driver is broken.
Have offered TI to fix it for a fee, (estimate that it is going to take me
about two days),
but they plan to do it themselves so if you are patient, wait for 2.6.13
where it hopefully will be included.

[Bekir Bahadir]

I'm also waiting for a fix to solve the USB hotplug issue

[b***@gmail.com]

Hii, I have a problem with the Beaglebone White's USB ports, I am doing a
project with this device and I want to be able to communicate with the
Beaglebone White with Python from my PC. I made a script .py in the
Beaglebone Bash, it starts automatically at startup the device and so this
the Beaglebone is left waiting a certain cararter to start the rest
execution of script, the problem comes when my PC sent the caracter and
Beaglebone I did not read in the USB port number ttyGS0 !! That may be
happening? I have to configure something to read me this port? Because
Beaglebone send data to the PC but the reverse is not, I have to set it as
a slave as it gets? Always working both terminals with USB serial ports
did not Ethernet or Sockets. Thanks, I hope your answers!