In my case I have a cape that connects via USB (besides the usual headers). And I have a TP on VBUS, sometimes just inserting a tester on the test point generates a Babble Interrupt.
Mine isn't properly grounded. You can always check the governor and cpu frequency with: juanjo@balin:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor ondemand juanjo@balin:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 300000 On Monday, November 4, 2013 12:12:53 PM UTC-3, Philippe Laurent wrote: > > A few more updates. I've read in a number of other locations that this > might be due to a grounding issue or a power draw issue. Starting with > tackling the power draw issue, it appears that the system bus outputs > different power to the USB device depending on its CPU throttling status. > The lower the CPU speed, the (slightly) lower the USB output. > > Still using Ubuntu 13.04, I've removed both the S99ondemand startup script > from the rc2.d folder, as well as placed the line " > > echo 'on' | tee /sys/bus/usb/devices/usb1/power/control" in the > /etc/rc.local script (no quotes) to try and mitigate the issue. The former, > from what I understand, keeps the CPU running at full speed, and does not > let it slow down based on demand, the latter works to keep USB power on to > the port at all times, rather than letting the BBB decide whether to power > it off/on. > > At this point, the BBB has not thrown any more Babble errors through > multiple power off/on events, nor through any extensive scanning or quiet > time. > > Of note, there may also be some merit in the grounding issue, as walking > across the floor and then touching the BBB case will occasionally cause the > Babble issue to appear and the Symbol device to power off. The device is > connected to a DC power supply, but there is no grounding plug with the > brick, so it stands to reason that the device is not grounded. > > Hope this helps someone... although I'm sure that at this point I have no > concrete solutions to the problem. > > On Saturday, November 2, 2013 12:32:03 PM UTC-4, Philippe Laurent wrote: >> >> Crap. On third reboot (full power off/on), the device is experiencing >> the same musb: Babble Interrupt error as before. >> >> So... this is a hardware issue? The BBB is powered by a separate adapter >> (not USB), so power shouldn't be the problem. >> >> On Friday, November 1, 2013 1:13:09 PM UTC-4, Philippe Laurent wrote: >>> >>> I resolved my issue by installing and using Ubuntu 13.04 on the BBB. >>> It's been up and running the python scanning script for over 24 hours, >>> which is roughly 23 hours longer than it has before. I used the >>> instructions at >>> http://shrkey.com/setting-up-beaglebone-black-to-boot-off-the-microsd-card/to >>> get the installation squared away. >>> >>> On Wednesday, October 30, 2013 9:51:30 AM UTC-4, Bekir Bahadir wrote: >>>> >>>> Same problem here. Im also willing to pay for a solution >>>> >>>> Am Samstag, 31. August 2013 17:42:09 UTC+2 schrieb [email protected]: >>>>> >>>>> I'm using my Beaglebone Black with a USB temperature sensor. It works >>>>> very well, however I noticed monitoring stopped last night after roughly >>>>> 35 >>>>> days uptime. This morning I looked more closely into the log file and >>>>> noticed: >>>>> >>>>> kernel: [2892926.929555] CAUTION: musb: Babble Interrupt Occurred >>>>> >>>>> I wasn't able to successfully reset the USB device and before I was >>>>> able to restart the BBB stopped responding. I power-cycled it and it was >>>>> back to normal again. Any ideas what caused this kernel message? >>>>> >>>> -- 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.
