Are the I/O lines the boot pins? Check the System Reference Manual for more information.
Gerald On Tue, Aug 26, 2014 at 3:54 AM, <[email protected]> wrote: > Hi, I don't know if my issue is the same described here, my BBB never > boots with something connected to I/O lines, if I disconnect, boots BBB and > then reconnected I/Os everything works fine. > > Em segunda-feira, 28 de outubro de 2013 19h18min20s UTC-2, AndrewTaneGlen > escreveu: > >> 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 <[email protected]> >>> 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 <[email protected]> >>>>> 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 < >>>>>>> [email protected]> 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, [email protected] >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> 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, >>>>>>>>> [email protected] wrote: >>>>>>>>>> >>>>>>>>>> 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 [email protected]. >>>>>>>> >>>>>>>> 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 [email protected]. >>>>>> 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 [email protected]. >>>> 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- 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.
