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?
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, <[email protected] <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- >>> 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] <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 [email protected]. For more options, visit https://groups.google.com/d/optout.
