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.
In the complete log that I posted where the -110 error occurs, this event appears:
[ 0.133639] vdd_mpu: 925 <–> 1325 mV at 1100 mV
When I review logs where that error does not occur, I see this instead:
[ 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.
In the log where the error occurs, this event appears:
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.
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:
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.
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.
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.
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
