On Thursday, November 20, 2014 8:35:49 AM UTC-5, [email protected] wrote: > > Ok, I have now got somewhere with this. What seems to be happening at > least on our custom design (similar to BBB) is: > > 1. We have an oscilloscope on the USB0 VBUS line. > 2. We have set the USB0 controller's mode to "peripheral" using the > DTB's dr_mode setting. > 3. When the g_ether gadget's module is loaded into the kernel the VBUS > line begins pulsing high (about 2V) once every 2 seconds. It appears that > the g_ether module causes the USB0 controller to ignore its "peripheral" > status and go into "otg" mode. I think in OTG mode the USB0 pulses the > VBUS > line to check on the capacitance of the line and thus see if a slave > devise > is attached. If one is the USB controller will go into host mode. It can't > really do this on our board as there is no ability to power the VBUS line. > 4. As the USB0 VBUS line is connected to the TPS65217's USB power > input it sees this pulsing. I guess once in a while it decides to move to > USB power and this fails so the system reboots. > > If this is the case a few things at fault here I think. > > 1. The TPS65217 should prioritise AC power over USB power and thus not > try to switch to USB power when AC power is present and not switch on mere > pulses (chip bug ?) > 2. The Linux USB stack (musb driver ?) should not allow the USB > controller to go into OTG mode when set to "host" or "peripheral". This > may > be in the musb driver or g_ether module ? (Linux kernel bug ?) > 3. The AM335x (we are using an AM3358BZCZ) CPU appears to drive the > USB0 VBUS line (we have changed the in-series resistor to 1k and can see > the pin driving), possibly with a current source, in order to check for > VBUS capacitance. The AM335x manual states this line is an analogue input > only not an output. So there is a documentation discrepancy there. > (documentation bug ?) > > Fixes are (I think): > 1. Look at the Linux kernel to try and see why it goes into OTG mode when > the g_ether module (may be other cases as well) is loaded and stop this > happening when the device is set to "peripheral" mode. We are using 3.12.10 > maybe this has been fixed in later versions ? > 2. Increase the value of the CPU's VBUS pins series resistor (maybe 10k > ?). Not sure if this will work yet. >
Well, this post seem to be the definitive investigation of the problem. I admire the persistence and follow-up documentation. I'm running a custom build off RCN github 3.18.0-rc3-bone1 and my system has run as expected since I changed USB0 to "peripheral", in a variety of stressed wifi chip configs slaved on a USB hub (e.g. one in normal mode, another in 802.11 RFMON mode - which overwhelms the single-core CPU.) I'm used a mix of wifi chips from Realtek and Ralink. And I'd love to investigate the whole gadget layer more.... So, my question is: what impact does the behavior have when USB0 is in "peripheral" mode? Is it a debilitating bug? I'm just not familiar enough with USB to understand the impact. Dave -- 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/d/optout.
