BeagleBone Black doesn't sometimes start. Only Power LED is on

GoogleGroups
81

Andrew,

I tried that already. The file …/include/config.h is automatically generated when recompiling. I added the two lines which I marked red below. After I recompiled the uboot source again, the new generated config.h file replaces the old one that i modified and does not have the two lines.

My question is that have the two lines got recompiled into the u-boot.img? Or am I missing something here?

/* Automatically generated - do not edit */
#define CONFIG_SERIAL1 1
#define CONFIG_CONS_INDEX 1
#define CONFIG_NAND 1
#define CONFIG_SYS_ARCH “arm”
#define CONFIG_SYS_CPU “armv7”
#define CONFIG_SYS_BOARD “am335x”
#define CONFIG_SYS_VENDOR “ti”
#define CONFIG_SYS_SOC “am33xx”
#define CONFIG_BOARDDIR board/ti/am335x
#define CONFIG_AUTOBOOT_KEYED 1
#define CONFIG_AUTOBOOT_DELAY_STR “uboot”
#include <config_cmd_defaults.h>
#include <config_defaults.h>
#include <configs/am335x_evm.h>
#include <asm/config.h>
#include <config_fallbacks.h>
#include <config_uncmd_spl.h>

82

Hi there Shu et al.

You don't have to remove the whole U15. You can just give a 3.3V
pull-up to the 4th PIN on the J1 connector. Then the board will not
be stuck at the UBOOT anymore.

Really?
My first hunch after reading Andrew and Marcus' posts was also that
the RX line just needed to be tied down. But after seeing that R165
already does this, my suspicion was that it might be caused by the
SN74LVC2G241 doing some hiccups on the CPU during early power because
of OE and _OE being constantly active.

This is contradicted of your above experience, or at least also makes
the noise dependent on the 241's 1A input, which agreed does also seem
plausible. Inserting a "pull up" as you suggest, however does make
this and R165 a voltage divider keeping the B_UART0_RX input on ~1.4V
(at least when 3V3 and DGND has stabilized). Have you tried if the
uart0 port is functional after this modification?

Inspired by your input I've now done more tests which confirms your
experiences. Find them here;
http://www.mikini.dk/index.php/2014/11/beaglebone-black-periodic-boot-failure-fixing-b_uart0_rx-with-voltage-divider

Funny thing though, I tried increasing the pull down done by R165
(100k->45k), that didn't alleviate the problem as I kind-of expected.
Could the issue be that DGND and/or 3V3 actually isn't stable in
periods where the 241 has power and is gating 1A through to 1Y?

My question is how to fix it from software perspective? In u-Boot
source, how can we make sure it is not stuck?

I've yet only skimmed the posts about the software fix, as I prefer
understanding the problem fully before settling on a fix.

I regard issues like this as a hardware flaw, and it needs to be fixed
in hardware. There might be software workarounds that can mend the
symptoms on already existing boards, but that is part 2 for me so I'm
not there, yet.

One suggestion could be that the uart driver/uboot itself flushes the
uart fifo during initialization, so that uboot only reacts on input
made during the execution of the code that checks for interactivity.
My guess is that the fifo gets filled with characters generated from
noise early during power up, and it just sits there until uboot comes
around yanking it out and interpreting it. I haven't looked at the
uboot code yet, so this is pure speculation.

Regards,
- --
    Mikkel
  ,= ,-_-. =.
((_/)o o(\_))
  `-'(. .)`-'
      \_/

83

Mikkel,

You can give a 3.3v directly or use a small resistor to make the voltage on the 4th pin of J1 higher than 3V. That should work. We rebooted a board over hundreds of time by using an app on Linux. It did not fail a single time.

We found this accidently by using serial cable and the board never fails to boot when the cable is connected. The serial cable gives the 3.3v to the 4th pin which is the UART0_RX.

We tried to figure out what cause the problem and found a weird thing. We measured the UART3_RX(D16), UART3_TX(D15), UART4_RX(pin11 on header P9) and UART4_TX(pin13 on header P9). They are all 3.3V and they are in UART mode. We removed the R165 which is the pull down resistor on the UART0_RX line. The UART0_RX is around 1.4V and sometimes floating. We also checked the device tree. The internal pull up of the UART0_RX is turned on.

uart0_pins: pinmux_uart0_pins {
pinctrl-single,pins = <
0x170 (PIN_INPUT_PULLUP | MUX_MODE0) /* uart0_rxd.uart0_rxd */

We do not know why the UART0_RX is not getting 3.3V, can you please check the voltage on both UART0_TX and UART0_RX when U15 is removed?

Again, If somebody can tell me how to fix it in uboot or from software perspective, I would really appreciate it.

Regards,
Shu

84

Hi Chu,

You can give a 3.3v directly or use a small resistor to make the
voltage on the 4th pin of J1 higher than 3V. That should work. We
rebooted a

Well, that is interesting, as it isn't consistent with my findings. I
guess you missed that I use a 82k5 ohms resistor as pull up. That's
where the 3,3V*(100k/(100k+82,5k)= 1.81V level on B_UART0_RX/J4.1 is
from (which I misstated as the 82k2's voltage drop of 1.4V in previous
post).

This is close to, but not surpassing, the high level voltage of U15
which is 2V at 3.3V VCC (datasheet p. 3), thus it will interpret my
B_UART0_RX as a low level. As my modification also solves the issue,
your assumption about your fix (a high level at J4.1/B_UART0_RX
(U15.2/1A)) is not true.

board over hundreds of time by using an app on Linux. It did not
fail a single time.

Nice, thought about doing something like that too while manually
plug/unplugging ;). Is that application available somewhere? It would be
nice to fully automate the test to really hammer this issue.
How do you notify the application of successful boot? Another BBB and
some IO's?

We found this accidently by using serial cable and the board never
fails

No-one can plan for good stuff, it just shows up. Nice find, I remember
having read your posting about it somewhere.

We measured the UART3_RX(D16), UART3_TX(D15), UART4_RX(pin11 on
header P9) and UART4_TX(pin13 on header P9). They are all 3.3V and
they are in UART mode.

Pins configurable for UART3 is used for MMC/MII, so I guess it is UART1
on TX;D15/P9.24 and RX;D16/P9.26 you have measured?

We removed the R165 which is the pull down resistor on the UART0_RX
line. The UART0_RX is around 1.4V and sometimes floating. We also
checked the device tree. The internal pull up of the UART0_RX is
turned on.

Peculiar, as it should never float.

We do not know why the UART0_RX is not getting 3.3V, can you please
check the voltage on both UART0_TX and UART0_RX when U15 is
removed?

I'll definitely look into this tomorrow. Including taking this
measurement.

Again, If somebody can tell me how to fix it in uboot or from
software perspective, I would really appreciate it.

Got hints or pointers on bulding uboot for BBB? There's a lot of
different how-tos/blogs out there.

Regads,
- --
    Mikkel
  ,= ,-_-. =.
((_/)o o(\_))
  `-'(. .)`-'
      \_/

85

Hi Chu.

As my modification also solves the issue, your assumption about
your fix (a high level at J4.1/B_UART0_RX (U15.2/1A)) is not true.

Sorry, J1.4 is the correct pin.
I've now done tests with a stronger pulldown (1k in parallel with R165=
990 ohm) and a short directly to DGND/VDD_3V3B (I'll post details later,
find them at Mikini Services » beaglebone black).

These tests confirm that B_UART0_RX can't be pulled down/up, to prevent
the failure to occur. But forming a stable voltage on the input using a
voltage divider (also using 0 ohm= short circuit!) does solve the
problem. That is; whether we form a stable 0.58V or a stable 3.3V on
B_UART0_RX the system will always boot.

Does anybody have definite confirmation (by scope measurements) that
U15.6 (1Y) really is flickering during early power? It would be exiting
to do some experiments showing how it is affected by the U15.3 (1A)
input. I think that is the core of this issue.

We removed the R165 which is the pull down resistor on the
UART0_RX line. The UART0_RX is around 1.4V and sometimes
floating. We also checked the device tree. The internal pull up
of the UART0_RX is turned on.

[UART0_RX on 1.4V or floating]

Peculiar, as it should never float.

I haven't been able to replicate that measurement. I got 3V3 on
UART0_RX (the one without B_, on the cpu side), except in early power
up. I see the voltage flickering shortly just after power is applied,
and in the same instance that kernel is loaded (USR0-USR3 leds starts
lighting up) there also some activity.

Are you sure that you actually did measure on U15.6? It isn't easy to
place the probes right on those small pads.

We do not know why the UART0_RX is not getting 3.3V, can you
please check the voltage on both UART0_TX and UART0_RX when U15
is removed?

I'll definitely look into this tomorrow. Including taking this
measurement.

Here they are, I see nothing unexpected here when things are static. I
also checked the U15 supply, which seems to be ok.

* BBB measurements on terminals of removed U15

** Device Under Test:
   Modified Beaglebone Black produced by CircuitCo (PCB REV B6, serial
   007142901445, marked "beaglebone"+ beagle logo and
   "beagleboard.org").
   Modified by removing U15 (uart0 buffer chip: SN74LVC2G241) and its
   decoupling capacitor C155.

** Equipment
*** Multimeter
    Brymen Elma BM515CF MOBILE LOGGER, MFG.#: 063391676.

*** Power Supply Unit
    Huawei HW-050200E3W, output 5V 2A, USB A-connector. Danish plug.
    Sourced from Huawei E589 mobile wifi.

*** Power Cable
    20 cm no-name USB A male connector to USB Mini-B male connector.

** Procedure
   Apply power to BBB through USB Mini-B connector.
   Use multimeter to measure voltage levels on exposed U15 terminals
   and related supply lines to check possible supply voltage drop.
   COM probe fixed at DGND on decoupling capacitor (terminal C155.DGND
   farthest from PCB edge).

** Measurements
   C155.VDD_3V3B: 3.352V (terminal nearest to PCB edge)

   U15.1: _1OE = 0V
   U15.2: 1A = 0V
   U15.3: 2Y = floating (flickering +-0.000,50V)
   U15.4: GND = 0V
   U15.5: 2A = UART0_RX = 3.335V
   U15.6: 1Y = UART0_TX = 3.195V
   U15.7: 2OE = 3.352V
   U15.8: VCC = 3.352V

   J1.1 = DGND = 0.000,02 V
   P2.20 = GND5 = 0.000,02 V
   FB4.1 = VDD_3V3B = 3.351 V

Regads,

Even more regads,
- --
    Mikkel
  ,= ,-_-. =.
((_/)o o(\_))
  `-'(. .)`-'
      \_/

86

Mikkil,

Thanks for you detailed answer.

U15.1: _1OE = 0V
U15.2: 1A = 0V
U15.3: 2Y = floating (flickering ±0.000,50V)
U15.4: GND = 0V
U15.5: 2A = UART0_RX = 3.335V
U15.6: 1Y = UART0_TX = 3.195V
U15.7: 2OE = 3.352V
U15.8: VCC = 3.352V

Based on the voltages that when U15 is removed, the UART0_RX is at its proper voltage level (3V3) that is defined in the device tree.

The strange thing is that when U15 is there, the UART0_RX is not getting 3V3. _1OE is low and 2OE is high. Then the voltage on the j4.4 should be the same as UART0_RX. But J4.4 is not 3.3V (it was 1.4 on my board) even when R165 is removed, therefore, UART0_RX is not 3.3V.

How did you get the 0.58V on J4.4 using 1K resistor? I do not why 0.58V works.

To my understanding, the default idle state should be high on both TX and RX lines for UART0.

Regards,
Shu

87

i have the same problem, could you tell me the how to get the device back …
thank

88

Hi Chandu.

i have the same problem, could you tell me the how to get the
device back ..

If you are experiencing the issue where uboot is put in interactive
mode by noise on UART0_RX during power up (see rest of this thread for
more details), then pushing the reset button will likely bring it
back. In the many many test I have done I've never seen the board not
recover from a reset in this situation.

The UART0_RX power up issue is periodic (in my tests failure rate was
24/555~4.3%).
If your board permanently starts up in this state (only pwr led is
lit) then my guess is that uboot is not loaded at all. Could your
image be corrupt? Have you attempted to reflash the emmc before seeing
this? Have you tried booting from a stock uSD image (holding down uSD
BOOT switch)?

A fix to the periodic UART0_RX issue is stabilizing B_UART0_RX which
can easily be done on the backside of the board. This doesn't affect
the functionality of UART0 (serial console).
See details about the fix here;
http://www.mikini.dk/index.php/2014/11/beaglebone-black-periodic-boot-failure-no-high-required-just-stable-voltage

Good luck.
- --
Mikkel

89

Hi,
Just as a +1 to Andrew’s findings:
I have done a simple test with two BBBs to verify the presence and fix of the boot issue. The BBB under test had pins 1 and 5 of its UART0 port connected to an FTDI converter cable, which was plugged into the second BBB’s USB port. The system reset pin (P9_10) of the BBB under test was wired to a GPIO pin on the other BBB. I then ran a shell script that pulled the reset pin high whenever “Starting kernel …” was being printed on the serial console, and counted the number of resets. After some cycles the board would enter the U-Boot console and get stuck there. In three attempts with an A6A board, it took 3, 64 and 37 resets respectively for the board to get stuck. On a rev. C board, the problem occurred after 24, 31 and 3 resets. The U-Boot version used for these tests is fairly old (U-Boot SPL 2013.04-rc1-14237-g90639fe-dirty (Apr 13 2013 - 13:57:11) / U-Boot 2013.04 (Apr 23 2013 - 18:26:39))

I then copied the fixed u-boot provided by Guglielmo (https://www.dropbox.com/sh/98xacnk466xfpza/uTlii1hrsg) to the board’s eMMC. When repeating the test, I now got past 1000 cycles on both BBBs (rev. A6A and rev. C) without a single boot failure.

In summary, this software fix is still highly useful.

Thank you Andrew and Guglielmo for your work!

Martin

90

Hi there Martin.

Just as a +1 to Andrew's findings: In summary, this software fix is
still highly useful.

Glad you were able to solve your issue.
I'm just wondering if Andrew's autoboot solution/hack hasn't
propagated to the official software yet?

Seems odd if not, since so many has been bitten by it and it is now 15
months since it was first described (2013-10-28:
Redirecting to Google Groups).

I haven't studied the u-boot source before but I just took a sniff at
the mainline repository (U-Boot / U-Boot · GitLab).
I found that for BBB (really am335x) u-boot still defaults to aborting
autoboot if any characters are received on the serial console and then
waiting forever for further commands.

Below is a patch mitigating this situation in mainline master
(binaries at
http://www.mikini.dk/wp-content/uploads/2015/01/u-boot_mainline_BBB-autoboot-patch_201501151.zip).
It requires typing more characters ("stop") to abort and uses a new(?)
config feature to reset the board if autoboot is aborted but no
commands are entered (for 30 sec).
Except for the 30 sec timeout, which doesn't kick in for some unknown
reason, it seems to behave ok.

Disclaimer: this is mostly an experiment, there is a lot of u-boot
trees and patches floating around for the BBB (like
GitHub - beagleboard/u-boot: mirror of https://git.beagleboard.org/beagleboard/u-boot), so probably mainline hasn't
got the most recent stuff for BBB yet.

diff --git a/include/configs/ti_am335x_common.h
b/include/configs/ti_am335x_common.h
index 5ed86d9..c58f467 100644
- --- a/include/configs/ti_am335x_common.h
+++ b/include/configs/ti_am335x_common.h
@@ -12,6 +12,12 @@
#ifndef __CONFIG_TI_AM335X_COMMON_H__
#define __CONFIG_TI_AM335X_COMMON_H__

+#define CONFIG_AUTOBOOT_KEYED
+#define CONFIG_AUTOBOOT_STOP_STR "stop"
+#define CONFIG_AUTOBOOT_PROMPT "autoboot in %d seconds (type '%s' to
abort)\n",bootdelay,CONFIG_AUTOBOOT_STOP_STR
+#define CONFIG_BOOT_RETRY_TIME 30
+#define CONFIG_RESET_TO_RETRY

91

Hi Mikkel,

I’m just wondering if Andrew’s autoboot solution/hack hasn’t
propagated to the official software yet?

It’s been a while that I haven’t looked at the preinstalled software of a BBB since I get them pre-flashed with my own image…
The official Angstrom image releases for BBB seem to be at Beagleboard:Updating The Software - eLinux.org (the page title is slightly misleading).
The most recent image dates from 2013-09-04, and the u-boot files on its boot partition are from 2013-06-19. This corresponds to the latest modification of [1], where apparently the u-boot patches for BBB are stored.
Clearly there is no fix yet! It looks like that repository is maintained by Koen Kooi, so maybe you can send him your patch.
Changing the upstream u-boot source probably doesn’t make sense since the issue does not apply to other am335x-based systems.

Thumbs up, also for Guillermo ;).

Indeed, I noticed that typo this morning. My apologies!

Thanks,
Martin

[1] - meta-beagleboard/common-bsp/recipes-bsp/u-boot/u-boot-denx at master · beagleboard/meta-beagleboard · GitHub

92

Mikkel,

I just found this forum after having these same boot problems with a couple beaglebones I have. I figured I would reply to you since I noticed you just posted a reply. I am a little confused on how to apply the fix Andrew provided. I am able to follow the instructions on downloading and building the u-boot, everything seems to work fine there. Then I have a MLO and u-boot.img file that I copy to the /boot/uboot directory ( I am using Debian booting off the eMMC). My question is when are the #DEFINES suppose to be added to the config.h file? Andrew mentions that he made the changes to the config.h file and rebuilt the u-boot, but when I do that it just overwrites the config.h file back to the original. So I assume the process should be first download and build the u-boot, then move MLO and u-boot.img into the uboot directory (/boot/uboot), then modify the config.h file adding in the #DEFINES Andrew provides. Is this correct? I have tried everything I can think of, but I you will have to forgive me because I am not too familiar with Debian. Thank you for any help you can provide!

93

Mikkel,

I just found this forum after a couple beaglebones I have starting displaying the same problem discussed here. I figured I would reply to you since I saw you just posted. I have a question on how to implement Andrew’s solution. I am able to download and build the u-boot, everything is working fine there. Then I have two files, MLO and u-boot.img that I can copy into the boot directory (/boot/uboot I am using Debian and booting from the eMMC). My question is when are we suppose to edit the config.h file? After I build and move the 2 files? I’m wondering because in Andrew’s post he mentions that he edited the config.h file then rebuilt the u-boot. But when I try this it just overwrites the config.h file back to the original. So I assume the process should be first download and build the u-boot, then move the MLO and u-boot.img to the boot directory, finally edit the config.h file. Is this correct? I have tried everything I can think of but my board is still hanging on boots about 1 out of 20. Forgive me because I am not too familiar with Debian. Thank you for any help you can provide!

94

Hi Patrick,

Ensure you modify config.h after running the clean and configure steps before compiling, otherwise it will re-copy the default configuration file.

Only once you have compiled with the correct config file should the u-boot image be copied over.

BTW there is a run-time config file for u-boot that can be used to achieve the same effect (i.e. without the need to rebuild and copy over u-boot) - this might be worth investigating as a lower-risk option.

Cheers,
Andrew.

95

Hi Andrew,

Thank you for your reply. I feel like this is steering me in the right direction but I have one more question. After I do the clean and configure steps, I am looking for the /include/config.h file but I don’t see it anywhere. I do see it after I do the compile step so it must be created after the compilation. Maybe I am missing something and looking for the wrong thing. Once I get this worked out it is going to save me a lot of frustration so thank you for all your help. Oh and also the runtime config file sounds like something I want to check out but a google search didn’t help me much. Which file would I be editing for this? Thank you!

96

Hi again Patrick.

After I do the clean and configure steps, I am looking for the
/include/config.h file but I don't see it anywhere.

You could do like in my mainline patch, add the options to a specific
am335x file (I used /include/configs/ti_am335x_common.h). What tree
are you building from?

Oh and also the runtime config file sounds like something I want to
check out but a google search didn't help me much. Which file
would I be editing for this? Thank you!

This option puzzled me too, hadn't thought this was possible, mostly
because in the boot sequence it seems like the environment is loaded
after the autoboot prompt.

I haven't tried it yet, but if you got the full source tree look for the
autoboot documentation in README and doc/README.autoboot.

In Denx's master you can use the env vars "bootdelaykey" or
"bootstopkey" to disable "any key" autoboot abort. But be sure u-boot is
built with CONFIG_AUTOBOOT_KEYED defined or else these options will not
be enabled.

Environment vars are what can be used at boot time to define how u-boot
should commence booting the OS, besides the options set at compile time.
The environment is read from the uEnv.txt file residing besides MLO and
u-boot typically on eMMC/flash or the SD-card. Normally BBB first tries
the eMMC, then SD. If the boot switch is depressed at powerup (not
reset) eMMC is skipped (actually SPI is tried instead) and u-boot on
the SD-card is used.

Anybody know if these options are available and enabled in u-boot on the
stock BBB images?

- --
    Mikkel
  ,= ,-_-. =.
((_/)o o(\_))
  `-'(. .)`-'
      \_/
keybase.io/mikini

97

The patch-delta used in the BBB images is available here:

https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2015.01/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch

It's built against the "am335x_evm" u-boot target..

Regards,

98

Hi Mikkel,

I am trying to follow Andrew’s post as close as I can. The tree I am building from is git:``//git.denx.de/u-boot.git, ``the one provided in Andrew's post.

99

Hellow Martin.

I'm just wondering if Andrew's autoboot solution/hack hasn't
propagated to the official software yet? It's been a while that I
haven't looked at the preinstalled software of a BBB since I get
them pre-flashed with my own image...

I haven't looked that much either since I settled on using the, then
latest, Debian 7.5 build from 2014-05-14 as base for our production
systems (which is still in limited deployment testing stage though).

But I see that this build is still regarded as the latest.

The official Angstrom image releases for BBB seem to be at
Beagleboard:Updating The Software - eLinux.org (the page
title is slightly misleading).

- From my perspective that page and Ångström is obsolete!

Debian is touted everywhere on the official pages as the most recent
distribution and also the one flashed on current BBB production HW
(look at Latest Software Images - BeagleBoard instead).
Also it is my experience that Debian is a lot easier to work with and
has fewer issues than the Ängström images.

It seems like this is the documentation on the official Beagleboard
Debian images complete with testing builds (most recent is 2014-12-31);
Beagleboard:BeagleBoneBlack Debian - eLinux.org. It also points
to how you can roll your own from github here;
GitHub - beagleboard/image-builder: Image builder.

I'll try this out, and prepare a patch for Roger et. al. if it isn't
there yet.

Changing the upstream u-boot source probably doesn't make sense
since the issue does not apply to other am335x-based systems.

Well, it wont't hurt them, just delay boot(!) a bit ;).
I thought it might be done upstream by enabling CONFIG_AUTOBOOT_KEYED
by default, thus a BBB specific uEnv.txt could configure a stop/delay
string using "bootdelaykey"/"bootstopkey" at boot time. This shouldn't
affect other systems.

That being said, I still regard this as a hardware issue on BBB. Hope
some of the hardware guys are following the discussion trying to
figure out from where the spurious characters are originating.

- --
    Mikkel
  ,= ,-_-. =.
((_/)o o(\_))
  `-'(. .)`-'
      \_/
keybase.io/mikini

100

Hi guys,

I am facing the same problem (power LED on, user LED off and board not booting).

It only happens occasionally. I wrote a script that reboots the board every 60s (using "shutdown -r now") to reproduce.

I then installed the "MLO" and "u-boot.img" files that are available in "https://www.dropbox.com/sh/98xacnk466xfpza/uTlii1hrsg" but the problem still happens occasionally.

I am not sure though I installed "MLO" and "u-boot.img" correctly - exactly which folder do these files have to be copied into?
I found existing "MLO" and "u-boot.img"files in "/opt/backup/uboot" so I copied the new files to that location. Or do I have to copy them to "/boot/uboot" instead?

Sorry if this seems to be a silly question - I am still quite new to the BBB and have been struggling with several issues. This issue is one of them; eth0 occasionally not connecting after reboot if static IP settings is another one (but that will be a separate post).

Thanks for all help; I am a bit in a desperate situation as my system (based on BBB) will be installed in an unattended environment where power failures are possible - so it is crucial that the boot rate is 100.00%!

Regards
Ivan