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. On Wednesday, November 19, 2014 10:06:09 PM UTC, RobertCNelson wrote: > > On Wed, Nov 19, 2014 at 3:57 PM, Rick Reynolds <[email protected] > <javascript:>> wrote: > > Just an FYI... > > > > We are currently working on a project using Rev C BBB and RCN > 3.13.11-bone12 > > kernel. We had been experiencing random reboots. Sometimes multiple > times > > per day and sometimes once per day, mostly at night. We determined that > the > > reboots were only occuring when the BBB was being powered only from the > 5VDC > > connector. We never saw a reboot when the BBB was either powered from, > or > > just connected to, the USB OTG port. > > > > One of our engineers suggested that it might be a noise issue on the USB > OTG > > port and the way that the TPS65217C PMIC works in the system. The way he > > explained it to me is that the PMIC is set up to default to the USB OTG > port > > for power. If you leave the USB OTG port open, or floating, while > powered > > from the 5VDC connector and then get noise on the USB OTG port then the > PMIC > > will attempt to switch to USB OTG port and finding that there is no > voltage > > there the system reboots. > > > > What we have done to solve the problem so far: I made a pigtail cable > for > > the USB OTG port that simply ties the shield, ground and 5VDC together. > > There is no 5VDC on the USB OTG port when not connected to a host > machine. > > Not a great final solution but it did prove the theory. With the pigtail > > installed we never get reboots, it's been tested on several BBBs now and > is > > very consistent. So, reboots regularly without the pigtail and never > with > > the pigtail installed. > > > > One other thing to note... On the schematic there are 4.7uF caps from > both > > the USB OTG and 5VDC lines to ground. We were thinking that this could > allow > > some relatively high frequency noise to pass to the PMIC. I don't know > what > > the response time, that would cause a switch over, is on the PMIC. It's > > possible that something on the order of a .01uF - .1uF cap from the USB > OTG > > 5VDC line to ground might also solve the problem. This has not been > tested > > yet however. > > Backport this line change (usb0:) > > > https://github.com/RobertCNelson/linux-stable-rcn-ee/blob/3.18-rc5-bone1/arch/arm/boot/dts/am335x-bone-common.dtsi#L97 > > > and nuke the "CONFIG_OTG" option.. > > Regards, > > -- > Robert Nelson > http://www.rcn-ee.com/ > -- 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.
