We have a problem with a custom board design based on an AM3358 and a TPS65217 PMIMC. The power supply arrangement is like a Beaglebone black. We (and others with Beaglebone blacks) have had an issue with intermittent reboots (about 1 every 12 hours).
We have tracked this down to Linux kernel issues and possibly TPS65217 issues, see below.
One point in this is that it appears that the AM335x generates an output on the USB0_VBUS pin probably to perform OTG probing. We have seen this using an oscilloscope. The AM335x manuals clearly state that the USB0_VBUS pin is an analogue input only.
Is the USB0_VBUS supposed to output a current when OTG polling as we have seen ?
=====================================================================================
Notes on problem
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 ?)
