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
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,
Can you ground the Vusb line? The same problem was with 3.2
Отправлено с iPad
Robert Nelson wrote:
Please upgrade to :
sudo apt-get update
sudo apt-get install linux-image-4.1.2-ti-r4
sudo rebootStill tracking the random reset down.
New kernel installed and running. Will report back in a day or two.
Cheers,
Erik
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
Probably yes. Anyway my boards had Vbus grounded and customers never complained
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.
Cheers,
Erik
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.
Erik
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
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,
Erik
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
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 . . .
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.
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 . . .
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
I Powered one from a USB power supply only with no random reboots
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.
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 . . .
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 setwget 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.
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..
Regards,