RESOLVED: Upon investigating the u-boot output we found we were facing the same problem reported earlier in this thread by duckhunter: u-boot was detecting spurious data on uart0 and entering the u-boot console on about 1/20 power-ups.
Rather than making any hardware mods I decided to reconfigured u-boot to look for a specific key sequence before entering the u-boot console. To do this I firstly downloaded and rebuilt u-boot following instructions here: http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot. (Testing with the default config produced the same 'failure' rate) I then modified '/include/config.h' in the u-boot source files, adding the following: #define CONFIG_AUTOBOOT_KEYED 1 #define CONFIG_AUTOBOOT_DELAY_STR "uboot" This now forces a user to enter the string 'uboot' before entering the u-boot console, otherwise the device will boot up normally. Rebuilding with this configuration still gave the same failure rate however. This is when I learned that the boot files on the eMMC flash are still loading before jumping to the files on the sd card I am using. So upon deleting the MLO file on the eMMC flash I had more luck. We setup a programmable power supply and a script looking at the output of uart0 to detect whether the device had successfully booted or had become stuck in u-boot, and then left it cycling power. We were then able to get many hundreds of consecutive successful boots - we only stopped the test because we decided it would probably never fail. So in the end it all came down to spurious data on uart0 - along with disabling booting from the eMMC. (we could have simply reconfigured u-boot on the eMMC in the same way, but disabling it drops a few seconds off the boot time). Thanks for all your help Gerald (and duckhunter). Regards, Andrew Glen. On Friday, 25 October 2013 10:00:44 UTC+13, Gerald wrote: > > That is correct. The power button is only good for shutting it down with > power attached and turning it back on with power still attached. > > UBoot uses the UART0 debug port on the header, J1, on the board. > > Gerald > > > > > On Thu, Oct 24, 2013 at 3:57 PM, AndrewTaneGlen > <andrewt...@gmail.com<javascript:> > > wrote: > >> When it fails to boot after connecting 5V, a short press of the power >> switch has no effect. The kernel has not booted, so the button press event >> is going nowhere. >> >> From this failure mode, pressing and holding the power switch until the >> power led goes off and then releasing it causes the device to boot - as >> does a short press of the reset switch. This is what has led me to the >> conclusion that the only way to guarantee the device boots after applying >> power is to control the reset signal with a watchdog circuit triggered off >> a transition of the heart-beat signal (or something similar). >> >> I'm wondering if it possibly is getting to u-boot under this failure >> mode. Do you know if any of the uarts available on P9 are configured by >> default for u-boot? >> >> Cheers, >> Andrew. >> >> On Friday, 25 October 2013 09:14:18 UTC+13, Gerald wrote: >> >>> You must just press the power button once. Not hold it. If you do >>> it just power cycles. Pressing the button once let's the Linux kernel >>> shutdown after a 60 second time out. >>> >>> Try it again using the power button as it was intended. >>> >>> Gerald >>> >>> >>> >>> On Thu, Oct 24, 2013 at 3:05 PM, AndrewTaneGlen <andrewt...@gmail.com>wrote: >>> >>>> Hi Gerald, thank you for your response. >>>> >>>> I tried the following (Using a new BBB with no SD card inserted, and >>>> nothing else connected to it at all): >>>> >>>> Firstly, plug in 5V barrel connector (connected to regulated 5V, >>>> measured with good multimeter as 5.0001V), then: >>>> >>>> 1) Wait to see he heartbeat led (D2) come on. >>>> >>>> 2) Press and hold the power key until the power led (D1) goes off. >>>> >>>> 3) Release the power key >>>> >>>> Repeating this process (with 5V connected the entire time) the device >>>> failed to boot (the heartbeat led failed to come on) on the 14th try, and >>>> continues to do so about 1/20. >>>> >>>> I'm using the BBB in a location away from any regular user interaction >>>> and with a power supply that can come on and go off randomly (it functions >>>> as a wifi client I connect to and control/monitor with an ipad), so >>>> unfortunately I don't have the ability to manually press the power or >>>> reset >>>> buttons to ensure the device always comes on when power is applied (at >>>> least as I intend to use it). >>>> >>>> What I will do, as a kind of nuclear option, is reassign the heart-beat >>>> led to a spare gpio on P9, and implement a basic watchdog circuit that >>>> will >>>> pull the 'SYS_RESETn' low for a couple of hundred milliseconds if it >>>> doesn't see a change in state of the heart-beat signal within about 10 >>>> seconds. This should give a 100% guarantee that (as long as the hardware >>>> is >>>> ok) the kernel will eventually get booted whenever power is applied. >>>> >>>> There is a TI part, the TPS382x that is nearly perfect for this task, >>>> but has a non-configurable delay time of 1.6s - I'll try to find something >>>> like this. >>>> >>>> Cheers, >>>> Andrew. >>>> >>>> >>>> >>>> >>>> On Friday, 25 October 2013 02:01:51 UTC+13, Gerald wrote: >>>> >>>>> I don't see that fix as being the issue you are seeing. But, when they >>>>> are available, you can certainly give it a try. >>>>> >>>>> The reset button is a warm reset button. It is not the power on reset >>>>> for the board. >>>>> >>>>> I suggest that you use the power button as it is intended and use it >>>>> to power off the board and then power on the board. See what sort of >>>>> results you get in that use case. >>>>> >>>>> Gerald >>>>> >>>>> >>>>> On Wed, Oct 23, 2013 at 9:41 PM, AndrewTaneGlen >>>>> <andrewt...@gmail.com>wrote: >>>>> >>>>>> Hello All, >>>>>> >>>>>> I am also having this problem - with a bench top power supply set to >>>>>> 5V and 5A, plugging into the barrel connector with no SD card inserted, >>>>>> so >>>>>> running the default Angstrom image from flash, the device will fail to >>>>>> boot >>>>>> at least 1 in 20 tries. A similar failure rate was observed on my two >>>>>> other >>>>>> boards. >>>>>> >>>>>> I noticed a new board revision has been a released - the A6. The list >>>>>> of revisions included a reference to fixing a random glitch in the >>>>>> SYS_RESETn signal. Could this possibly address the problem I have been >>>>>> seeing - I would be more than happy to buy more boards if this is the >>>>>> case. >>>>>> >>>>>> Regardless of the new release, I have tried various experiments to >>>>>> find a 100% reliable way of making the A5C board boot, as follows: >>>>>> >>>>>> 1) Hold reset button, connect power, release reset button after ~1 >>>>>> second. >>>>>> >>>>>> 2) Connect power, press and hold reset button, then release after ~1 >>>>>> second. >>>>>> >>>>>> 3) Hold Power button, connect power, wait till power led goes off, >>>>>> then release power button. >>>>>> >>>>>> All of these also failed at varying rates, but all showing at least >>>>>> one failure out of 40 tries - which is unfortunate as I am building a >>>>>> custom cape that will have access to the reset and power signals, so I >>>>>> there was some sure fire way of making it boot this would have been >>>>>> fairly >>>>>> easy to include in my design. >>>>>> >>>>>> Any further info would be greatly appreciated. >>>>>> >>>>>> >>>>>> Regards, >>>>>> Andrew. >>>>>> >>>>>> >>>>>> On Saturday, 28 September 2013 10:04:06 UTC+12, gmbe...@gmail.comwrote: >>>>>>> >>>>>>> Same problem here, its showing up in 2 ways. The Beagle Board Black >>>>>>> has a power control IC that is sensitive to 5 volt rise time and has >>>>>>> frozen >>>>>>> up under short brownout situations..in fact, I can freeze it up at will >>>>>>> by >>>>>>> dropping out 5 V for about 100mS, it will lock up with 3.3 volts turned >>>>>>> off >>>>>>> even though the 5 volt input is good. Removing the 5 volt input for >>>>>>> more >>>>>>> than 1 second restores normal 3.3 Volt power and all is good. The other >>>>>>> way..I'm still investigating, it refuses to boot about 1 in 20 tries >>>>>>> for >>>>>>> reasons that are so far unknown. In this instance I have power supply >>>>>>> monitoring instruments all over this board, and the power supply >>>>>>> controller >>>>>>> is working even when the lockup occurs. So I'm mainly interested in the >>>>>>> situation where the blue lights are on but the board is not booting. We >>>>>>> are >>>>>>> running a port of Debian Linux. >>>>>>> >>>>>>> >>>>>>> On Wednesday, July 31, 2013 5:48:54 PM UTC-4, >>>>>>> duckhunt...@gmail.comwrote: >>>>>>>> >>>>>>>> Hi guys, >>>>>>>> >>>>>>>> we have a problem with our Beagle Bone Black (A5C). We are using >>>>>>>> Ubuntu Raring 13.04 armhf v3.8.13-bone21 (2013-06-14) on the eMMC (no >>>>>>>> SD >>>>>>>> Card). The Beagle Bone is placed in a case and we have connected it to >>>>>>>> a DC >>>>>>>> power supply. Sometimes (I would say every 5 to 10 times), when we are >>>>>>>> plugging in our power supply, the BeagleBone powers on (Power LED is >>>>>>>> on), >>>>>>>> but nothing more happens (none of the other four LEDs is on). If we >>>>>>>> are now >>>>>>>> removing the power supply and putting it in again, the BBB starts >>>>>>>> normally. >>>>>>>> I guess the power supply is strong enough: 5A@5V. >>>>>>>> >>>>>>>> Thanks for your help in advance. >>>>>>>> >>>>>>>> Regards, >>>>>>>> duckhunter >>>>>>>> >>>>>>> -- >>>>>> 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 beagleboard...@**googlegroups.**com. >>>>>> >>>>>> For more options, visit >>>>>> https://groups.google.com/**grou**ps/opt_out<https://groups.google.com/groups/opt_out> >>>>>> . >>>>>> >>>>> >>>>> -- >>>> 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 beagleboard...@**googlegroups.com. >>>> For more options, visit >>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> >>>> . >>>> >>> >>> -- >> 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 beagleboard...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
