From: <vago...@gmail.com> Reply-To: "beagleboard@googlegroups.com" <beagleboard@googlegroups.com> Date: Thursday, August 28, 2014 at 6:00 PM To: "beagleboard@googlegroups.com" <beagleboard@googlegroups.com> Subject: Re: [beagleboard] Re: BeagleBone Black doesn't sometimes start. Only Power LED is on
> That's it, I was using the boot pins, the System Reference Manual says that I > can use this pins after Reset signal, how can I do this? If you power your board from the 3V3B rail or use this power rail to enable power on your own board, then you should be OK. If you power your board before the 3V3B pin is powered, you will damage the processor and you will most likely have a boot problem. Regards, John > > Valdir > > Em terça-feira, 26 de agosto de 2014 17h11min52s UTC-3, Gerald escreveu: >> 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, <vag...@gmail.com <javascript:> > 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-Bootl >>>> oader:U-Boot >>>> <http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Boot >>>> loader: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> >>>>> 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.com >>>>>>> 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, duckhunt...@gmail.com >>>>>>> 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 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. >>>>>>> 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. >>>>>> 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/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 beagleboard+unsubscr...@googlegroups.com. > 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
