BBB intermittently rebooting.

[Erik de Castro Lopo]

HI all,

I have BBB that is rebooting about once a day for no good reason.

Its powered from an external plug pack (usb host adapator not even
connected), its running the 4.1.1-bone9 kernel from the
BBB-eMMC-flasher-debian-8.1-console-armhf-2015-07-05-2gb.img
image.

There are no clues in /var/log/messages or syslog or anywhere
else.

Anyone with any suggestions on how to debug this?

Cheers,
Erik
--
Erik de Castro Lopo <mle...@mega-nerd.com>

[Robert Nelson]

On Fri, Jul 17, 2015 at 7:00 PM, Erik de Castro Lopo
<mle...@mega-nerd.com> wrote:
> HI all,
>
> I have BBB that is rebooting about once a day for no good reason.
>
> Its powered from an external plug pack (usb host adapator not even
> connected), its running the 4.1.1-bone9 kernel from the
> BBB-eMMC-flasher-debian-8.1-console-armhf-2015-07-05-2gb.img
> image.
>
> There are no clues in /var/log/messages or syslog or anywhere
> else.
>
> Anyone with any suggestions on how to debug this?

Please upgrade to :

sudo apt-get update
sudo apt-get install linux-image-4.1.2-ti-r4
sudo reboot

Still tracking the random reset down..

Regards,

--
Robert Nelson
https://rcn-ee.com/

[Max]

Can you ground the Vusb line? The same problem was with 3.2

Отправлено с iPad

> 18 июля 2015 г., в 3:19, Robert Nelson <robert...@gmail.com> написал(а):

> --
> 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/d/optout.

[Erik de Castro Lopo]

Robert Nelson wrote:

> Please upgrade to :
>
> sudo apt-get update
> sudo apt-get install linux-image-4.1.2-ti-r4
> sudo reboot
>
> Still tracking the random reset down.

New kernel installed and running. Will report back in a day or two.

Cheers,
Erik
--

[Erik de Castro Lopo]

Max wrote:

> Can you ground the Vusb line? The same problem was with 3.2

Are you referring to this?

https://groups.google.com/forum/#!msg/beagleboard/xPxzYyNsA78/XllFv6ZHUWIJ

Cheers,
Erik
--

[Maxim Podbereznyy]

Probably yes. Anyway my boards had Vbus grounded and customers never complained

18 Июл 2015 г. 12:36 пользователь "Erik de Castro Lopo" <mle...@mega-nerd.com> написал:

[Erik de Castro Lopo]

Maxim Podbereznyy wrote:

> Probably yes. Anyway my boards had Vbus grounded and customers never
> complained

How can I test if Vbus is grounded on my board? If its not, is that a
modification I can do? Is it documented somewhere? I've googled but not
been able to find anything.

[Erik de Castro Lopo]

Erik de Castro Lopo wrote:

> New kernel installed and running. Will report back in a day or two.

With kernel linux-image-4.1.2-ti-r4 it rebooted after about 10 hours
of uptime.

[Maxim Podbereznyy]

It is NOT grounded by default otherwise you would not be able to power the board from USB. I don't know how you can ground the Vbus line. I would take a soldering station (I have two) and put a simple short from the Vbus pin at a USB connector to the ground.

OR you can power the board from USB and ensure that no random reboots occur. The problem appear when Vbus line is floating

19 Июл 2015 г. 1:57 пользователь "Erik de Castro Lopo" <mle...@mega-nerd.com> написал:

[Erik de Castro Lopo]

Maxim Podbereznyy wrote:

> OR you can power the board from USB and ensure that no random reboots
> occur. The problem appear when Vbus line is floating

Ah, thank you. That's what I needed to know. Going to look into supplying
power over USB (only).

Thanks,

[Graham]

Eric:
You never said what you were trying to do with the BBB, and why you need Debian 8.1/kernel 4.x.x.
As you have seen, it is temporarily broken, but is being worked on. This is a "test" release, and not recommended for active use, unless you like adventures, like you are having.

If you need the capemanager, consider Debian 7.8/kernel 3.8

If you don't need the capemanager, but need some other benefit of Debian 8, then use Debian 8.x and kernel 3.14.

Both of these options are solid, do not reboot by themselves, and don't care whether it is powered from the 5V barrel connector or USB.
--- Graham

==

[William Hermans]

Graham, thats where you're wrong. I've been using all those testing kernels EXACT SAME KERNELS you've been having troubles with. Except, I'm not having troubles with them. Why ? Becasue I'm powering via USB.

So if you REALLY want to prove the problem this won't work for *you* try powering via USB . . .

--

[Graham Haddock]

My advice to Erik is that, if he has something important to do, to go back to an official release.  He should use a "Beta" release only if he can afford the additional problems it might bring, and in this case there are some.  In my application for the BBB, I do not use or want to use the USB connector. The previous kernels worked fine with the +5V power.  Although the +5V versus USB power behavior could be an important clue to what the problem is.

==

When you say "powered by USB" are you also running the USB g_multi interface to a PC and engaging the driver in the PC?

Or, are you just powering it via the USB connector and not using/engaging the USB subsystem in the BBB?

I think there are (at least) two variables here.

I will go power my BBB via the USB connector, which will power the Vusb line, but without any USB activity on the USB connector and see what happens.

I agree that systemd is not the likely problem, since kernel 3.14 uses systemd, and works fine, USB or +5V connector.

My personal observation is that the less the BBB is doing, the more likely the self-reboot is to happen.

If I turn off the four blinking blue LEDs, with the BBB not doing anything else, the reboots seem to happen more often.

So, if you are powering the USB connector from a computer, it may be the USB activity, not the power source that is changing the behavior.

--- Graham

==

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/2yOpE3XYJ1Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[William Hermans]

Or, are you just powering it via the USB connector and not using/engaging the USB subsystem in the BBB?

Not sure if g_multi or g_ether is setup on this image. In either case, I'm only using ethernet. I'll look though. *looks*

Looks like the answer is "no".

debian@beaglebone:~$ lsmod
Module                  Size  Used by
snd_soc_evm             5854  0
omap_rng                5140  0
rng_core                8755  1 omap_rng
snd_soc_davinci_mcasp    18528  2
snd_soc_edma            1166  1 snd_soc_davinci_mcasp
snd_soc_hdmi_codec      2514  1
uio_pdrv_genirq         3657  0
uio                     9930  1 uio_pdrv_genirq

 

Anyway, I can understand that you may not want to use USB to power the device. However as a test to see if vbus / vusb is floating . . . this can not really hurt to power via USB for a little while during tests.

Once it is established that this problem is related or not, then you and others can act accordingly. Grounding the necessary lines, or not.

This really makes sense to me though, at least from my own perspective. Since I'm not having the problems you all are having with the same kernels. Passed that, if it does not pan out. Well, a little wasted time, but well worth the effort considering this problem seems to plague several people. Easy enough to test anyway . . .

[Graham Haddock]

Yes, I will go run the USB-Power test.

I guess my question is... are you are powering your BBB from the USB port on a computer, or, are you powering your BBB via the USB port from something like a power supply or cellphone charger, which does not have a computer and USB driver in it.

If you are powering the BBB from a computer, and that computer has the BBB driver on it, that allows you to see the BBB's internal web site, etc, then, even though you are not using it, when you plug it in, the driver comes up and starts polling the BBB at 1000 times per second, to see what is going on. A lot is happening at the lower levels of USB that take time to service on the BBB.

--- Graham

==

[evilwulfie]

I Powered one from a USB power supply only with no random reboots

[William Hermans]

Well, the driver module is not loaded - period. Otherwise with lsmod, it'd show up as g_multi, g_ether, g_serial, or very unlikely as g_mass_storage. To put your mind at ease though, this is a stock instal of wheezy 7.8 console image. Using APT to install the linux-image 4.1.x kernel. The console images as I recall from Robert saying it on these forums multiple times. Do not have the gadget drivers enabled by default. The only reason why I did not know for sure, was that I usually, on my own disable systemd through uEnv.txt, and add g_ether to /etc/modules. Which loads the ethernet gadget driver at system bring up. But I did not in this case . . .

So To answer more succinctly. I have always powered my boards from USB connected to a laptop - always. Wulfman, my buddy has powered one or more of the 3 boards by various means. Barrel jack, USB to laptop, and USB to walwart adapter. As far as I am aware, he has had no problems related to this issue. But he usually sticks to tried an true images. Where as I'm more of the experimenter in this case.

[William Hermans]

So I should also add that I'm not an electronics engineer by any stretch of the imagination. However, I do know various things about power, and digital electronics. Most of which I picked up from Wulfman, who has been an EE for 35+ years . . .

Digital electronics 101, a floating trace / line is a "bad" trace / line. So my reasoning on a trace that goes directly to a PMIC, on a trace that can control the PMIC to power and maybe reset the board . . . all it takes is a power fluctuation to reset the board . . . Everything "screams" this to me - However.

Wulfman has looked through the datasheet for the PMIC, and even the schematics for the eval board of this PMIC( from TI ), and can not see why / how this would / could happen.

Anyway, I have no idea how this PMIC is connected to the system through software. I *think* I remember reading something about it being connected through I2C1 . . . but that is a vague memory at best.  I do remember that uboot can control the PMIC in the same way that the linux kernel does though. For whatever that is worth . . .

[john dough]

Sent from my Windows Phone

---

From: William Hermans
Sent: ‎7/‎19/‎2015 11:11 AM
To: beagl...@googlegroups.com
Subject: Re: [beagleboard] BBB intermittently rebooting.

[Maxim Podbereznyy]

As far as I remember how the Vbus issue was described in details, hope I'm not mistaken:

Vbus connects to both CPU and PMIC. CPU has a charge-pump circuit to detect OTG devices (inject some power and track USB signals for incoming events) and it injects 5V periodically into Vbus line. Sometimes PMIC detects this 5V on the Vbus input as a good voltage and turns inner power switch to Vbus where in fact no 5V with sufficient current. Next power failure and immediate reboot occur

LinkedIn - http://www.linkedin.com/in/maximpodbereznyy

Company - http://www.linkedin.com/company/mentorel

Facebook - https://www.facebook.com/mentorel.company

[Graham Haddock]

William/Wulfman: So far, running on USB Power module (no USB communications) the BBB is staying up. It has been 18 hours or so now.  Running the same software that rebooted twice in 24 hours on +5V barrel connector input.  I have seen the 'bad' configuration run as long as 36 hours between reboots, so the test needs to continue for at least two days.

Thanks to Maxim for the explanation.  If that is the problem, it looks like the problem existed in 2013, a software patch was applied, and the software patch was lost between kernel 3 and kernel 4.

--- Graham

==

On Mon, Jul 20, 2015 at 2:41 AM, Maxim Podbereznyy <lisa...@gmail.com> wrote:

As far as I remember how the Vbus issue was described in details, hope I'm not mistaken:

Vbus connects to both CPU and PMIC. CPU has a charge-pump circuit to detect OTG devices (inject some power and track USB signals for incoming events) and it injects 5V periodically into Vbus line. Sometimes PMIC detects this 5V on the Vbus input as a good voltage and turns inner power switch to Vbus where in fact no 5V with sufficient current. Next power failure and immediate reboot occur

2015-07-20 3:08 GMT+03:00 john dough <softw...@live.com>:

Sent from my Windows Phone

---

From: William Hermans
Sent: 7/19/2015 11:11 AM

--

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/2yOpE3XYJ1Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[evilwulfie]

usb0_vbus on the processor is an analog input to a comparator.
page 80 of the processor ref manual says - USB0_VBUS (7) Supply voltage for USB VBUS comparator input
i do not see it saying supplies any voltage to the circuit anywhere in the PDF.
I can see the software causing the issue if there is some kind of noise in the line.
maybe instead of a hard ground which would cause headaches if one was to plug a usb power connector to the BBB
a pulldown of 10k on the line to keep it low.
One would need to test this idea out.

Gerald might have a comment ?

[William Hermans]

William/Wulfman: So far, running on USB Power module (no USB communications) the BBB is staying up. It has been 18 hours or so now.  Running the same software that rebooted twice in 24 hours on +5V barrel connector input.  I have seen the 'bad' configuration run as long as 36 hours between reboots, so the test needs to continue for at least two days.

Thanks to Maxim for the explanation.  If that is the problem, it looks like the problem existed in 2013, a software patch was applied, and the software patch was lost between kernel 3 and kernel 4.

--- Graham

Glad to hear that so far everything seems good Graham. So far. However I have a sneaking suspicion it will continue to run until you decide to shut it off. Not 100% sure though, hence the need for someone like you to test. In hopes of narrowing down this problem.

[Graham Haddock]

William:

OK. I plan to let it run for at least two days, perhaps three.

--- Graham

On Mon, Jul 20, 2015 at 11:34 AM, William Hermans <yyr...@gmail.com> wrote:

William/Wulfman: So far, running on USB Power module (no USB communications) the BBB is staying up. It has been 18 hours or so now.  Running the same software that rebooted twice in 24 hours on +5V barrel connector input.  I have seen the 'bad' configuration run as long as 36 hours between reboots, so the test needs to continue for at least two days.

Thanks to Maxim for the explanation.  If that is the problem, it looks like the problem existed in 2013, a software patch was applied, and the software patch was lost between kernel 3 and kernel 4.

--- Graham

Glad to hear that so far everything seems good Graham. So far. However I have a sneaking suspicion it will continue to run until you decide to shut it off. Not 100% sure though, hence the need for someone like you to test. In hopes of narrowing down this problem.

On Mon, Jul 20, 2015 at 9:10 AM, evilwulfie <evilw...@gmail.com> wrote:

usb0_vbus on the processor is an analog input to a comparator.
page 80 of the processor ref manual says - USB0_VBUS (7) Supply voltage for USB VBUS comparator input
i do not see it saying supplies any voltage to the circuit anywhere in the PDF.
I can see the software causing the issue if there is some kind of noise in the line.
maybe instead of a hard ground which would cause headaches if one was to plug a usb power connector to the BBB
a pulldown of 10k on the line to keep it low.
One would need to test this idea out.

Gerald might have a comment ?

On 7/20/2015 12:41 AM, Maxim Podbereznyy wrote:

As far as I remember how the Vbus issue was described in details, hope I'm not mistaken:

Vbus connects to both CPU and PMIC. CPU has a charge-pump circuit to detect OTG devices (inject some power and track USB signals for incoming events) and it injects 5V periodically into Vbus line. Sometimes PMIC detects this 5V on the Vbus input as a good voltage and turns inner power switch to Vbus where in fact no 5V with sufficient current. Next power failure and immediate reboot occur

2015-07-20 3:08 GMT+03:00 john dough <softw...@live.com>:

Sent from my Windows Phone

---

From: William Hermans
Sent: 7/19/2015 11:11 AM

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/2yOpE3XYJ1Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[William Hermans]

For what it is worth . . .

debian@beaglebone:~$ uname -a
Linux beaglebone 4.1.2-ti-r3 #1 SMP PREEMPT Tue Jul 14 06:54:47 UTC 2015 armv7l GNU/Linux
debian@beaglebone:~$ cat /etc/dogtag
BeagleBoard.org Debian Image 2015-03-01
debian@beaglebone:~$ uptime
 19:46:56 up 6 days,  5:48,  1 user,  load average: 0.00, 0.01, 0.05

Powered via USB, and running ever since I installed that kernel

[dl4mea]

Since we now have two threads about the same problem...
https://groups.google.com/forum/#!topic/beagleboard/lF1X1XINjDo

My 13 BB-Black under test are powered from external +5V with these power supplies:
http://www.deutronic.com/products/power-supplies/ac-adapter/esc15g-15-watt.html
Average reboot number of each BB-B was each about 3 per day.

After reading this thread, I simply connected a USB cable from the front side Type-A to the back side Mini-USB and since then the number of reboots drastically decreased, within the last 12h I saw in total just two.
Other systems under my control but not located in my lab are showing the same improvement.

--- Günter (dl4mea)

[Maxim Podbereznyy]

I could in my archive messages:

I can confirm that the pulsing detected by PMIC on USB_DC signal is the probing from USB-OTG. 

 

After I disabled the USB-OTG in the kernel, the system has never rebooted. Btw I also re-loaded Angstrom image (3.8 kernel) and Andrew's Android image (with 3.8 kernel). I did not observe USB-OTG probing pulses on the VBus. I believe in the 3.8 kernel, the USB-OTG has not been implemented/enabled. That might be reason why it seems that 3.8 kernel doesn't have the random reboot behavior.

In case anyone wants to test it out, here is the change in the source code (NOTE: ignore the line and column numbers; just search for the struct "static struct omap_musb_board_data musb_board_data" ):

...

--- a/arch/arm/mach-omap2/board-am335xevm.c

+++ b/arch/arm/mach-omap2/board-am335xevm.c

...

 

@@ -3956,7 +4125,8 @@ static struct omap_musb_board_data musb_board_data = {

  * mode[4:7] = USB1PORT's mode

  * AM335X beta EVM has USB0 in OTG mode and USB1 in host mode.

  */

- .mode           = (MUSB_HOST << 4) | MUSB_OTG,

+// .mode           = (MUSB_HOST << 4) | MUSB_OTG,

+ .mode           = (MUSB_HOST << 4) | MUSB_PERIPHERAL,

  .power = 500,

  .instances = 1,

 };

--
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/d/optout.

[Robert Nelson]

Thanks Maxim,

On Tue, Jul 21, 2015 at 2:45 AM, Maxim Podbereznyy <lisa...@gmail.com> wrote:
> I could in my archive messages:
>
> I can confirm that the pulsing detected by PMIC on USB_DC signal is the
> probing from USB-OTG.
>
>
>
> After I disabled the USB-OTG in the kernel, the system has never rebooted.
> Btw I also re-loaded Angstrom image (3.8 kernel) and Andrew's Android image
> (with 3.8 kernel). I did not observe USB-OTG probing pulses on the VBus. I
> believe in the 3.8 kernel, the USB-OTG has not been implemented/enabled.
> That might be reason why it seems that 3.8 kernel doesn't have the random
> reboot behavior.
>
> In case anyone wants to test it out, here is the change in the source code
> (NOTE: ignore the line and column numbers; just search for the struct
> "static struct omap_musb_board_data musb_board_data" ):

This shouldn't be an issue, as we define what they are..

&usb0 {
status = "okay";
dr_mode = "peripheral";
};

&usb1 {
status = "okay";
dr_mode = "host";
};

but just in-case we have a regression somewhere else, i'll push out a
test with otg disabled. (it's enabled in 3.14.x and we need it for the
x15)

[Robert Nelson]

diff --git a/patches/defconfig b/patches/defconfig
index 79ae693..7731b6a 100644
--- a/patches/defconfig
+++ b/patches/defconfig
@@ -4070,7 +4070,7 @@ CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
#
CONFIG_USB_DEFAULT_PERSIST=y
CONFIG_USB_DYNAMIC_MINORS=y
-CONFIG_USB_OTG=y
+# CONFIG_USB_OTG is not set
# CONFIG_USB_OTG_WHITELIST is not set
# CONFIG_USB_OTG_BLACKLIST_HUB is not set
# CONFIG_USB_OTG_FSM is not set


wget http://rcn-ee.homeip.net:81/farm/testing/linux-image-4.1.2-ti-r4.6_1cross_armhf.deb
sudo dpkg -i linux-image-4.1.2-ti-r4.6_1cross_armhf.deb
sudo reboot

[Graham]

Robert:

I can also confirm the behavior of rebooting on +5V Barrel power, and no reboots when on USB power.
Same hardware, same OS/Software, running on +5V barrel input reboots about three times per day,
randomly.  Same-same on USB power (iPhone 1A charger, no USB activity) has been running without
reboot for almost two days, now.

I can also confirm that this reboot problem does NOT exist in 3.14. I have Debian 8.1/kernel 3.14
that have been running for multiple weeks on +5V barrel power, without reboot.

There have been some significant recent changes to USB power that allow tablets to both push
power out of a connector to power thumbdrives, etc, as well as take power in the SAME connector
for battery charging.  It is a kludge of a system if I have ever seen one.  You might want to see if
any of this new USB power code has affected things.

--- Graham

BBB1 -- Debian Image 2015-07-12
uname -a
Linux BBB1 4.1.2-ti-r4 #1 SMP PREEMPT Thu Jul 16 20:48:37 UTC 2015 armv7l GNU/Linux

================================================

Power supply from Adafruit 2A on +5V barrel connector.

Jul 18 15:42:10        Initial Boot
Jul 18 15:50:47        My Reboot
Jul 18 16:07:08        My Reboot after kernel update

Jul 18 23:10:07        Autonomous Reboot
Jul 19 05:27:54        Autonomous Reboot

Jul 19 16:50:08        Test terminated for other power source testing

===============================================

Power supply is Apple iPhone 5W (1A) on USB port

Jul 19 17:05:48        My Reboot after power supply change

:~# uptime
(JUL 21)  13:20:13 up 1 day, 20:15,  1 user,  load average: 0.00, 0.01, 0.05

=================================================

[Maxim Podbereznyy]

By the way I with my collegues spent some time on investigating this issue and found in the tps65217 datasheet that all three power source Vac, Vusb and Vbat should not be enabled at the same time. Only two of them should. Because of the reason that BBB is a universal enthusiast's board all three power sources are left floating, which contradicts with tps65217 architecture. We figured out that if the most of users use only a barrel connector or USB then Vbat input should be grounded. I don't know if this solution fixes the random reboot issue but at least it complies with the TPS65217 architecture. Probably anybody should try to ground the Vbat input and see how the board behaves.

--

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/d/optout.

[Dennis Cote]

On Tuesday, July 21, 2015 at 8:06:49 AM UTC-6, lisarden wrote:

By the way I with my collegues spent some time on investigating this issue and found in the tps65217 datasheet that all three power source Vac, Vusb and Vbat should not be enabled at the same time. Only two of them should. Because of the reason that BBB is a universal enthusiast's board all three power sources are left floating, which contradicts with tps65217 architecture. We figured out that if the most of users use only a barrel connector or USB then Vbat input should be grounded. I don't know if this solution fixes the random reboot issue but at least it complies with the TPS65217 architecture. Probably anybody should try to ground the Vbat input and see how the board behaves.

I was reviewing the TPS65217 datasheet and I think this may be the area of concern (from section 9.3.9.1):

The linear charger periodically applies a 10-mA current source to the BAT pin to check for the presence of a battery. This will cause the BAT terminal to float up to > 3 V which may interfere with AC removal detection and the ability to switch from AC to USB input. For this reason, it is not recommended to use both AC and USB inputs when the battery is absent. 

Since the battery is absent for most BBB users, TI recommends using AC or USB power, but not both.

Furthermore, the TPS65217 has internal sinks on the AC and USB inputs, so it should not be necessary to short either input to ground when it is not used as long as the input sinks have not been forced off by the software. 

9.3.9.4 AC and USB Input Discharge 

 

AC and USB inputs have 90-µA internal current sinks which are used to discharge the input pins to avoid false detection of an input source. The AC sink is enabled when USB is a valid supply and VAC is below the detection threshold. Likewise, the USB sink is enabled when AC is a valid supply and VUSB is below the detection limit. Both current sinks can be forced OFF by setting the [ACSINK, USBSINK] bits to 11b. Both bits are located in register 0x01 (PPATH). 

 

NOTE [ACSINK, USBSINK] = 01b and 10b combinations are not recommended as these may lead to unexpected enabling and disabling of the current sinks. 9

Perhaps someone can check if these are being set to something other than 00b.

Dennis Cote 

 

[Maxim Podbereznyy]

You can disable in software Vac or Vusb, but not the battery source, that is why so much trouble

22 Июл 2015 г. 1:25 пользователь "Dennis Cote" <den...@harding.ca> написал:

--

[dl4mea]

Am Mittwoch, 22. Juli 2015 08:45:40 UTC+2 schrieb lisarden:

You can disable in software Vac or Vusb, but not the battery source, that is why so much trouble

What about adding a 1k resistor from the VBat+ input to ground, just for safety?

[Dennis Cote]

On Wednesday, July 22, 2015 at 1:55:55 AM UTC-6, dl4mea wrote:

What about adding a 1k resistor from the VBat+ input to ground, just for safety?

That should not be necessary. The battery detection logic is complicated, but seems quite robust. Again from the datasheet:

9.3.13 Battery Detection and Recharge 

 

Whenever the battery voltage falls below VRCH, IBAT(DET) is pulled from the battery for a duration tDET to determine if the battery has been removed. If the voltage on the BAT pin remains above VLOWV, it indicates that the battery is still connected. If the charger is enabled (CH_EN = 1), a new battery charging cycle begins.

 

If the BAT pin voltage falls below VLOWV in the battery detection test, it indicates that the battery has been removed. The device then checks for battery insertion: it turns on the charging path and sources IPRECHG out of the BAT pin for duration tDET. If the voltage does not rise above VRCH, it indicates that a battery has been inserted, and a new charge cycle can begin. If, however, the voltage does rise above VRCH, it is possible that a fully charged battery has been inserted. To check for this, IBAT(DET) is pulled from the battery for tDET and if the voltage falls below VLOWV, no battery is present. The battery detection cycle continues until the device detects a battery or the charger is disabled.

 

When the battery is removed from the system the charger will also flag a BATTEMP error indicating that the TS input is not connected to a thermistor.

The one problem I see with the BBB design is that the test currents are applied to the BAT terminals and the battery voltage is measured on the BAT_SENSE terminal. Normally these would be connected at the battery, but they are not connected at all on the BBB. Perhaps connecting TP5 and TP6 with a jumper wire will help.

Dennis Cote

[dl4mea]

wget http://rcn-ee.homeip.net:81/farm/testing/linux-image-4.1.2-ti-r4.6_1cross_armhf.deb
sudo dpkg -i linux-image-4.1.2-ti-r4.6_1cross_armhf.deb
sudo reboot

It improves the situation, but there are still some reboots.
After 12h operation, 5 of my 14 BBB are still up since reboot, the others have seen reboots, one outstanding has had 4 oft them.

[William Hermans]

diff --git a/patches/defconfig b/patches/defconfig
index 79ae693..7731b6a 100644
--- a/patches/defconfig
+++ b/patches/defconfig
@@ -4070,7 +4070,7 @@ CONFIG_USB_ANNOUNCE_NEW_

DEVICES=y
 #
 CONFIG_USB_DEFAULT_PERSIST=y
 CONFIG_USB_DYNAMIC_MINORS=y
-CONFIG_USB_OTG=y
+# CONFIG_USB_OTG is not set
 # CONFIG_USB_OTG_WHITELIST is not set
 # CONFIG_USB_OTG_BLACKLIST_HUB is not set
 # CONFIG_USB_OTG_FSM is not set

wget http://rcn-ee.homeip.net:81/farm/testing/linux-image-4.1.2-ti-r4.6_1cross_armhf.deb
sudo dpkg -i linux-image-4.1.2-ti-r4.6_

1cross_armhf.deb
sudo reboot

Robert, was this image ever proven to reboot> Totally missed your post here somehow . . . but need to get some code written using live data from can0, and 3.8.x is somehow unstable with this setup.
 

 

[Robert Nelson]

Yeah, that one rebooted..

Give this one a shot:

http://rcn-ee.homeip.net:81/farm/testing/v4.1.x/linux-image-4.1.4-ti-r8.1_1cross_armhf.deb

boards 1 & 2 listed here:
http://rcn-ee.homeip.net:81/farm/uptime/

Are running that right now.. 9 hours +...

It's based on Nuno's git bisect log, with just a revert of the one commit..

[William Hermans]

Yeah, that one rebooted..

Dahm, ok . .

Give this one a shot:

http://rcn-ee.homeip.net:81/farm/testing/v4.1.x/linux-image-4.1.4-ti-r8.1_1cross_armhf.deb

boards 1 & 2 listed here:
http://rcn-ee.homeip.net:81/farm/uptime/

Are running that right now.. 9 hours +...

It's based on Nuno's git bisect log, with just a revert of the one commit..

Ok cool. Yeah, ran into insufficient power with a USB walwart adapter . .. can0 was refusing ot come up after a while.

Also, I have another unrelated question. Ever see an install start acting wierd after losing power ? Our battery bank went over temp this morning and inverers shut off leaving the BBB in question in a lurch. Now . . . sudo requires a passwd every use. Was considering using fsck, but it's a live /home directory NFS share . . . :/

[William Hermans]

These TI kernels support nfsroot ?

U-Boot SPL 2014.04-00014-g47880f5 (Apr 22 2014 - 13:23:54)
reading args
spl_load_image_fat_os: error reading image args, err - -1
reading u-boot.img
reading u-boot.img


U-Boot 2014.04-00014-g47880f5 (Apr 22 2014 - 13:23:54)

I2C:   ready
DRAM:  512 MiB
NAND:  0 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment

Net:   <ethaddr> not set. Validating first E-fuse MAC
cpsw, usb_ether
Hit any key to stop autoboot:  0
gpio: pin 53 (gpio 53) value is 1
mmc0 is current device
gpio: pin 54 (gpio 54) value is 1
SD/MMC found on device 0
reading uEnv.txt
638 bytes read in 5 ms (124 KiB/s)
gpio: pin 55 (gpio 55) value is 1
Loaded environment from uEnv.txt
Importing environment from mmc ...
Checking if uenvcmd is set ...
gpio: pin 56 (gpio 56) value is 1
Running uenvcmd ...
reading vmlinuz-4.1.4-ti-r8.1
8195768 bytes read in 452 ms (17.3 MiB/s)
reading /dtbs/4.1.4-ti-r8.1/am335x-boneblack.dtb
57860 bytes read in 17 ms (3.2 MiB/s)
Kernel image @ 0x80300000 [ 0x000000 - 0x7d0eb8 ]
## Flattened Device Tree blob at 815f0000
   Booting using the fdt blob at 0x815f0000
   Using Device Tree in place at 815f0000, end 81601203

Starting kernel ...

[Robert Nelson]

On Fri, Aug 7, 2015 at 7:13 PM, William Hermans <yyr...@gmail.com> wrote:
> These TI kernels support nfsroot ?

They should. ;)

bone kernel: bone patchset + mainline
ti kernel: bone patchset + ti patchset + mainline..

[William Hermans]

Ok, I'm stuck in a boot loop, what you see above is what I keep getting. Let me explore some.

[William Hermans]

Starting new post . . .

[William Hermans]

So far shorting Vusb to ground seems to be doing the trick. We'll give it a couple days to be "sure". Prior to shorting Vusb to ground, this linux image would reboot several times a day ( 4-5 )

william@xanbustester:~$ uptime
 13:20:26 up 15:28,  3 users,  load average: 0.01, 0.02, 0.05
william@xanbustester:~$ uname -r
4.2.0-rc4-bone2

[Maxim Podbereznyy]

William, or short Vusb to 5V, the result is the same - total stability. You can do it if you need to enable the USB-Host function at USB0

[William Hermans]

Hi Maxim,

The reason why we did this is that the board in question was mounted to a piece of wood, that is screwed into a wall. So grounding Vbus would not have been easy. Vusb for us was really easy. Solder the outside pins on a USB A socket to the outer shielding, then plug a MALE A to mini B cable to the socket, and BBB. Took a total of like 5 minutes . . .

Normally I do not worry about any of this, and use USB power. Except this time for this project we needed the canbus running, and powering via USB cause the canbus to be less than reliable.

[Maxim Podbereznyy]

you can power a board by USB but from a special wall adapter with an integrated USB socket. As an option

[William Hermans]

you can power a board by USB but from a special wall adapter with an integrated USB socket. As an option

Yes, and we tried it. It was not enough power. It is also my understanding that powering the BBB in such a way can not give more than 500ma. It was not enough power. the canbus would not function at all part of the time. As soon as I applied power via barrel jack. Then problem went away.

[Maxim Podbereznyy]

probably you used a wall adapter with integrated monitoring chip which does not allow to overcurrent 500mA. You should use a dumb version of such device when it simply supplies as much power as it can :)

[William Hermans]

probably you used a wall adapter with integrated monitoring chip which does not allow to overcurrent 500mA. You should use a dumb version of such device when it simply supplies as much power as it can :)

Was simply a guess on my behalf. As I recall Gerald saying that the USB will not pull more than 500ma.

[Robert Nelson]

On Tue, Aug 11, 2015 at 10:47 AM, William Hermans <yyr...@gmail.com> wrote:
>> probably you used a wall adapter with integrated monitoring chip which
>> does not allow to overcurrent 500mA. You should use a dumb version of such
>> device when it simply supplies as much power as it can :)
>
>

> Was simply a guess on my behalf. As I recall Gerald saying that the USB will
> not pull more than 500ma.

I believe the pmic needs to talk with something on the usb bus...
that's why dumb usb chargers don't always work for powering the bbb..

[William Hermans]

I believe the pmic needs to talk with something on the usb bus...
that's why dumb usb chargers don't always work for powering the bbb..

Well, that I could not say. This is actually the first time I've run into USB power not being enough. I probably could have swapped USB wall adapters, but why ? Pretty sure none of the others we have would have worked either. Barrel jack + Vusb to ground is working fine :)

[Robert Nelson]

On Tue, Aug 11, 2015 at 11:04 AM, William Hermans <yyr...@gmail.com> wrote:
>> I believe the pmic needs to talk with something on the usb bus...
>> that's why dumb usb chargers don't always work for powering the bbb..
>
>
> Well, that I could not say. This is actually the first time I've run into
> USB power not being enough. I probably could have swapped USB wall adapters,
> but why ? Pretty sure none of the others we have would have worked either.
> Barrel jack + Vusb to ground is working fine :)

While that's a quick hardware hack, I'm having pretty good luck with
the revert..

revert: 4.1.4-ti-r8.1
http://rcn-ee.homeip.net:81/farm/uptime/test-bbb-1.log

reboot happy: 4.1.4-ti-r8
http://rcn-ee.homeip.net:81/farm/uptime/test-bbb-3.log

[William Hermans]

While that's a quick hardware hack, I'm having pretty good luck with
the revert..

revert: 4.1.4-ti-r8.1
http://rcn-ee.homeip.net:81/farm/uptime/test-bbb-1.log

reboot happy: 4.1.4-ti-r8
http://rcn-ee.homeip.net:81/farm/uptime/test-bbb-3.log

Yeah. Mayhaps I'll check it out once we run the generator again - In a couple days. 30kW onan cummings to pump water + transfer switch is slow enough most of the time that it wont keep the BBB up.

That image has the change you implemented ? for mii or whatever it was ( I forget ).

[William Hermans]

Changing linux-image's on my nfsroot setup is a bit of a hassle though. Have to manually copy / move all the boot files, and dtb's. IF I were better with shell scripts I'd probably write one lol.

[Robert Nelson]

On Tue, Aug 11, 2015 at 11:39 AM, William Hermans <yyr...@gmail.com> wrote:
> Changing linux-image's on my nfsroot setup is a bit of a hassle though. Have
> to manually copy / move all the boot files, and dtb's. IF I were better with
> shell scripts I'd probably write one lol.

Yeah, 4.1.4-ti-r9 has both the nfs mii change and the musb revert. So
when have lots of spare time for upgrades, don't pick anything earlier
than that for nfs. ;)

[William Hermans]

Yeah, 4.1.4-ti-r9 has both the nfs mii change and the musb revert. So
when have lots of spare time for upgrades, don't pick anything earlier
than that for nfs. ;)

OK cool - thanks. I'll pick a day when I'm not in a hurry to get things done. As usually the only real hassle is when I'm in a hurry, and make mistakes . . . because I'm thinking too much about the other things, and not enough of the job at hand :/

Hence why I usually have notes on hand for things like this, but not in this case. I should probably remedy that . . .