We have been having a similar problem with an AM335x design using the TPS65217 connected like a Beaglebone black. We are using the 3.12.10 kernel and saw system resets every 14 hours or so. We had set the USB ports to be host and peripheral types (in the boards DTB) , however we still saw, on an oscilloscope, pulses on the peripheral's USB VBUS line from OTG probing. Removing USB support from the kernel appears to fix the reboot problem. On current investigations, the OTG probing only starts after we load the g_ether module. To sum up, we think there are issues in at least the 3.12.10 kernel where USB OTG probing still happens even when the USB device is set to peripheral mode. Am looking at kernel sources to see why this may be so.
On Saturday, November 15, 2014 2:06:36 PM UTC, Ives van der Flaas wrote: > > The problem still isn't fixed on my end, but I've certainly been getting > closer. > > I've tried > - Disabling all watchdog timers in u-boot and Linux, still crashes > - A different 5V power supply, still crashes > - Disconnecting all USB devices, still crashes > > And to ensure I don't have faulty hardware, I tried running on a different > BBB (still crashes) as well as changing the kernel to the old 3.8 (does not > crash). > > The one thing I have found that actually works, is disabling the custom > application that's running all the time. The application uses pcscd to > constantly poll (interrupt based wasn't supported) if a smartcard is being > inserted. I have to suspect that through these repeated USB reads, I'm > somehow triggering the same bug that Jens and David could eliminate by > disabling OTG. > > As to how I could actually pinpoint that bug, I really have no idea - the > USB subsystem is rather complicated. All help is welcome. > > Op zondag 9 november 2014 19:50:46 UTC+1 schreef david turvene: >> >> On Saturday, November 8, 2014 10:01:52 AM UTC-5, Ives van der Flaas wrote: >>> >>> However, not enoug of a difference apparently. I just had a sudden reset >>> occur. This is on a 3.18-rc2-bone1 with both a Dymo labelwriter and a >>> smartcard reader attached through USB. >>> >> >> Jens Peter Schroer gave me the recipe to make it work in my >> configuration. I tried to enter an issue in >> http://bugs.elinux.org/projects/beaglebone-black/issues but it kept >> giving me an internal error, so I'm adding it here. >> >> There are a number of google group threads with similar characteristics >> to this issue; search group for: >> >> * "Beaglebone Black Rebooting Several Times Every Day" >> * "Beaglebone Black Random Reboot" >> * "3.17.1-rc4 sudden reset" >> >> Scenario: >> * BBBv3 >> * 3.17.1-rc4, 7.6 wheezy >> * usb0 is NOT connected >> * running BBB headless, control through uart and SSH >> * usb1 has a hub with one to three wireless plugs >> * 1.5A 5V power source >> >> Goal is a low-cost wifi monitor where the wifi plug runs with two >> interfaces: one in standard 802.11 mode and the second in monitor/otherbss >> mode capturing all traffic. I use the netlink iw package to add the second >> interface and set it to 802.11 monitor mode. I use wireshark to read on >> that interface and save packets to the sdcard. The normal interface is >> used for SSH control/monitor of the BBB. >> >> Initially the system ran okay using the wifi but when I ran the second >> monitor, it silently reboot at erratic times but all within 3 hours. There >> was no cause indication on the console or the logs. I built a couple >> versions of the kernel, up to 3.18.0-rc3-bone1, and tried a pre-built RCN >> image - all showing the same problem. >> >> Jens Peter Schroer emailed me a possible solution, which I have attached, >> of forcing usb0 to act as a peripheral and not OTG. His solution worked for >> my configuration. >> >> It appears there are other configurations that manifest the same silent >> reboot that the changing of usb0 dr_mode DOES NOT fix. >> >> -- 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.
