I have captured a BBB A5B random reboot with the oscilloscope (see attached image).
Ch1 → VDD_3V3B (P9.4) Ch2 → VDD_5V (P9.6) Ch3 → SYS_5V (P9.8) Ch4 → SYS_RESETn (P9.10) This confirms that the random reboot is produced by 1 second SYS_5V fall. Best regards. 2013/11/20 <[email protected]> > After reading the Jakub thread the new conclusion is that this seems to > bee a hardware related problem (related to PMIC). This may explain why > changing kernel or changing CPU frequency doesn't resolve the problem (only > minimizes it). > > I will test the Jakub hardware workaround (external MOSFET) in my own > system. > > About your questions: > > - I'm using a BBB A5B with a custom cape that includes: a LVDS converter > for a LCD, a resistive touchscreen, a MAX3232 converter for a RS232 port > and a buffer for some push buttons. > > - I have recompiled the TI 3.2 kernel (from LINUXEZSDK-BONE v06.00) to > include the proper LCD initialization. > > - The system runs a Qt application with CPU load below 10%. The CPU works > all time at default 1 GHz frequency. > > - I have two identical systems under test and I got one reboot each 2 to 3 > hours but some days both systems work without reboots for 10 to 15 hours. > > > Best regards. > > > El miércoles, 20 de noviembre de 2013 19:33:26 UTC+1, Lei Wang escribió: > >> It seems that Angstrom 3.8 kernel is more robust. But I couldn't confirm >> that it will resolve the random reboot issue. I haven't done long term >> testing. I remember seeing someone also has problem with it. It could be >> just that kernel is more optimized which draws less current. >> >> Limiting the CPU frequency only made BBB random reboot less often. I can >> confirm that. I believe it is also related to the current draw. The slower >> the clock the less the power is drawn from PMIC. >> >> By plugging in both DC power and USB cable (mini connector), it increases >> the PMIC current capacity. PMIC has two power paths (AC->SYS and USB->SYS), >> which reduces the stress placed on a single path (AC->SYS). I am suspecting >> the PMIC thermal shutdown causes the random reboot. Please take a look at >> the other thread I mentioned in a previous post. Jakub suggested putting in >> a Mosfet to bypass VDD_5V to SYS_5V path after boot up. >> >> BTW, could you tell me what is your setup besides using TI prebuild >> kernel? Are you driving a HDMI display or a LCD cape? what else do you >> connect to the BBB? >> >> Thanks, >> >> Lei >> >> >> On Wednesday, November 20, 2013 12:28:36 PM UTC-5, [email protected]: >>> >>> I confirm that I have the same issue with a BBB A5B using TI 3.2 kernel. >>> >>> After reading the full thread I guess that the posible workarounds are: >>> >>> - Using Angstrom 3.8 kernel. >>> - Powering the BBB from USB. >>> - Limiting the CPU frequency. >>> >>> Can anybody confirm it? >>> >>> Best regards. >>> >>> >>> El martes, 12 de noviembre de 2013 15:37:07 UTC+1, Lei Wang escribió: >>>> >>>> I have similar issue. I have (2) versions of BBB (A5A and A5C). They >>>> both randomly reboot themselves while I am running TI prebuilt BBB android >>>> image (from a couple hours to ten to fifteen hours). When I plug in the USB >>>> (DC is still powered) for logging with logcat, the reboot issue seems to >>>> disappear. >>>> >>>> I don't have problem with BBB Angstrom image (based on 3.8 kernel). I >>>> don't have problem with Andrew Henderson's android image (based on 3.8 >>>> kernel) either. >>>> >>>> Another issue is that when I run TI BBB android image, the clock >>>> randomly jumps forward 2^17 seconds. This happens on both of my BBB boards. >>>> The problem goes away when I run Angstrom or Andrew's android. >>>> >>>> I suspect it has something to do with the processor, DDR3 (BBB: AM3359 >>>> 1GHz + 512MB DDR3), the configuration, or apply workaround of errata. We >>>> have an AM335x EVM kit (AM3359 720MHz + 256MB DDR2). I also loaded TI >>>> prebuilt android image. I have run it for several months. It is rock solid. >>>> I never had problem with it. >>>> >>>> Here are the links to my other posts in regarding to this issue. >>>> https://groups.google.com/forum/#!category-topic/beagleboard/advanced/ >>>> 5qSJ4dQdar4 >>>> http://e2e.ti.com/support/embedded/android/f/509/t/297726.aspx >>>> >>>> >>>> >>>> On Thursday, October 31, 2013 6:32:16 PM UTC-4, Illutian Kade wrote: >>>>> >>>>> And now the board won't power on from the Debug Port, but will form >>>>> the DC jack. At this point I'm about to say "fuck this shit". >>>>> >>>>> On Saturday, October 5, 2013 7:12:06 AM UTC-4, Illutian Kade wrote: >>>>>> >>>>>> Has anyone experienced their BBB rebooting at random? >>>>>> >>>>>> It was running solid for two days straight and this morning it just >>>>>> keeps rebooting. This last time the power light even went out. >>>>>> >>>>>> *I've checked and all cables are secured. The entire setup is running >>>>>> of a PFC UPS; so power fluctuations shouldn't be an issue. >>>>>> >>>>>> *CPU doesn't seem to be under load; ~20% utilization >>>>>> >>>>>> *I've done a total unplug-let-sit and restart >>>>>> >>>>>> *From what logs I've looked through (message and kern.log) the board >>>>>> does a total restart and loses even the date (goes form Oct 5 to Aug 26) >>>>>> >>>>>> *I've not made any changes other than unplugging the Syba C-media USB >>>>>> sound card and transferring it back to my main computer after I wake up >>>>>> (BBB is doubling as a media player) >>>>>> -This has worked for a grand total of 'uptime' 2 days and some odd >>>>>> hours with no issues. >>>>>> >>>>>> ..I really hope this doesn't mean the board is defective :\ >>>>>> >>>>>> OS: Debian Wheezy (BBB-eMMC-flasher-debian-7.1-2013-08-26.img) >>>>>> Power: AC Adapter (http://www.adafruit.com/products/276) >>>>>> [specifically recommended by Adafruit] >>>>>> >>>>> -- 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/groups/opt_out.
<<attachment: capture.png>>
