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.
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
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.
Hi i had the same problem.
My solution is to plug the barrel connector first and then plug the adaptor into the wall socket.
The it boots always.
Hi Gerald,
We encountered exactly the same issue described above with several BeagleBone revision A5C.
Do you plan to fix it in the next hardware board revision? Or must we systematically update the bootloader with the patch from Andrew Glen?
Many thanks
Regards,
Ludovic
Thanks Gerald.
You changed C24 to a 2.2uF capacitor to improve the reset signal but we don't think that fix the issue.
We made some measurements around UART0 and we are convinced that u-boot detects spurious data during start up. Find below 2 ocilloscope screenshots (CH1 : PIN 3-J1 B_UART0_TX, CH2 : PIN 4-J1 B_UART0_RX).
http://hpics.li/9d7742f
http://hpics.li/956957a
RX signal looks noisy when TX signal changes. Maybe a coupling issue?
Regards,
Ludovic
Could be. That issue we have not seen. The one we did see was addressed by the capacitor change. I will look at this for a later revision, assuming we can duplicate it. But it won’t be in the next revision for sure.
Gerald
Get one of the latest version and try it. There was a change made back on Rev A6 that tied the 3V3B power up to the 3V3A. The 3V3B rail was coming up before the 3V3A rail. That may help this issue.
Gerald
quick question: How do I find out the hw rev version of my beagle bone black? i can’t seem to locate it visually on the board itself…
It is the big white label on the expansion header. There are pictures of it in the System Reference Manual.
Gerald
Can you post step by step instruction how to compile a new uboot and replace the old uboot in the BBB internal storage?
We tried the steps on the link you provided and got a new uboot.img and tried coping it to boot partition /media/beaglebone but it corrupted the obit partition.
We appreciate any help you can provide.
Pedro
My A6 version just “bricked” probably due to my ineptitude in creating a bootable SD card. I only get a power light when powered by either brick or USB. The serial debug interface just says “CCCCCCC…” continuously.
This may be a different issue than reported in this thread, but the results are the same: no boot.
Is there hope?
Gary
Yes, there is hope. You cannot brick the board if you can create a bootable SD card to reflash from.
http://elinux.org/Beagleboard:Updating_The_Software
Gerald
Hi Gerald,
Last measurements were performed with an A6 revision board. We don't think the 3V3 power up update fix this issue.
We will try the bootloader solution described by AndrewTaneGlen.
I hava a similar problem, just it almost everytime does not boot. I have 1.2A and nothing connected, just uSD card inserted. Also tried to flash the eMMC or boot from uSD, no success. And when it boots one of a hundret tries and i do not diconnect the power source an just reboot in shell, it is the same again.
Can anybody please help me?
Not sure what your issue is. You may need to request and RMA and get it looked at to see if there is a HW issue. 1 time out of 100 seems to indicate there could be an issue in the HW.
Gerald
Just another data point. I’m running an A5C and about 1/8 times when I restart with a watchdog timer it won’t restart. I have to hit the HW reset button to restart it. Even then I’ve noticed it sometimes doesn’t restart.
Kind of nullifies the value of the watchdog, I’m bummed. Guess I’ll hook my Wemo up to the power supply. 
Even SHUTDOWN -r not always work!