[beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2014-11-24 Thread terry . barnaby47
I think I have found the reason for this. See the "3.17.1-rc4 sudden reset " thread. On Monday, November 24, 2014 11:28:17 AM UTC, Thomas O wrote: > > Hey i do have some updates regarding this! We have

[beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2014-11-24 Thread Thomas O
Hey i do have some updates regarding this! We have now ran 10 bbb boards with a strap between 5v vcc and the v+ input on the USB connector. These now all have an uprime of 10+ days. The controls that are powered from the same power supply but do not have the strap has an average uptime of 8-9 h

Re: [beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2014-03-05 Thread Damien
Thanks Lei. this fix works! I ran the BB for 8 days without problem. On Thursday, February 27, 2014 1:51:26 AM UTC+11, Lei Wang wrote: > > Damien, > Check the link on TI e2e: > http://e2e.ti.com/support/embedded/android/f/509/t/308616.aspx > It basically switched the clock source from 32K to 24MH

Re: [beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2014-02-26 Thread Lei Wang
Damien, Check the link on TI e2e: http://e2e.ti.com/support/embedded/android/f/509/t/308616.aspx It basically switched the clock source from 32K to 24MHz clock. It eventually fixed my time jump problem. Good luck! On Tuesday, February 25, 2014 10:34:38 PM UTC-5, Damien wrote: > > Strange ... I c

Re: [beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2014-02-26 Thread Lei Wang
Damien, Check the link on TI e2e: http://e2e.ti.com/support/embedded/android/f/509/t/308616.aspx It basically switched the clock source from 32K to 24MHz clock. It eventually fixed my time jump problem. Good luck! Lei On Tue, Feb 25, 2014 at 10:34 PM, Damien wrote: > Strange ... I checked the

Re: [beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2014-02-25 Thread Damien
Strange ... I checked the commit and found it had been included within the v2013.04 uboot release .. but my BB board is still experienced with this time jump issue one/two times per day. Could there be anything else? Regards. Damien On Monday, February 24, 2014 3:23:46 PM UTC+11, RobertCNelson

Re: [beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2014-02-23 Thread Robert Nelson
Probably.. http://git.denx.de/?p=u-boot.git;a=commit;h=000820b5835c2b8b863af992b66dc973dc4bd202 On Feb 23, 2014 10:19 PM, "Damien" wrote: > Hi Robert, > Do you know more detail about the time jump issue in uboot? for example, > fix commit number, or some words used for the commit? > I am interest

Re: [beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2014-02-23 Thread Damien
Hi Robert, Do you know more detail about the time jump issue in uboot? for example, fix commit number, or some words used for the commit? I am interested to find out what exactly the fixes are, but there are too many commits in uboot and I need some thing to search with. Regards, Damien On We

Re: [beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2014-02-19 Thread Thomas Jannaud
The problem was fixed on my side with the new kernel https://github.com/RobertCNelson/armv7-multiplatform 2014-02-19 15:09 GMT+01:00 Illutian Kade : >

Re: [beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2014-02-19 Thread Illutian Kade
I RMA-ed it using the Beagle Board website. Took about 20 days, round trip, to get the board back. I doubt even if I had the skills to replace circuit chips, I'd would have been able to find itI have no idea how they diagnose issues for their boards. But you may have another issue. As mine

Re: [beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2014-02-19 Thread Jukka Mykkänen
Hey, I have to BBB:s (A6) that boots randomly with Ubuntu installed. How the PMIC was fixed, did you do it or send it back to shop?` -Jukka maanantai, 10. helmikuuta 2014 21.04.51 UTC+2 Illutian Kade kirjoitti: > > Turns out it was a faulty PMIC. It's been fixed and is happily blinking > away

Re: [beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2014-02-10 Thread Illutian Kade
Turns out it was a faulty PMIC. It's been fixed and is happily blinking away :D On Monday, February 10, 2014 5:55:30 AM UTC-5, Thomas J wrote: > > Hi > any news on this issue ? I have the same problem with my beagle xm, with > linux not running anything and it still reboots after 1 to 5 minutes

Re: [beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2014-02-10 Thread Thomas J
Hi any news on this issue ? I have the same problem with my beagle xm, with linux not running anything and it still reboots after 1 to 5 minutes If there is anything electric to do to make this work (add a capacity in front of the 5V power supply, ...) I can do it, I have lots of electronic tool

Re: [beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2013-12-10 Thread Gerald Coley
Please request an RMA so we can look at it. Make sure it is in the failed state and that you let the RMA team know how to get it in that state and recover. Gerald On Tue, Dec 10, 2013 at 9:45 AM, Illutian Kade wrote: > Sigh, nope, Angstrom 3.8 (disabled OTG detection) didn't fix the issue > e

Re: [beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2013-12-10 Thread Illutian Kade
Sigh, nope, Angstrom 3.8 (disabled OTG detection) didn't fix the issue either. As of late, the BBB actually powers down completely (power LED is off). And pressing the power button, reset button, even BOOT button does nothing. Hell, even unplugging and plugging back in the power doesn't do anyt

Re: [beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2013-12-05 Thread Illutian Kade
Crap...now to figure out if this is doable (by me) for Debian Wheezy. ...if computers become sentient, it's probably because I goofed something up. On Thursday, December 5, 2013 12:10:18 PM UTC-5, Lei Wang wrote: > > I can confirm that the pulsing detected by PMIC on USB_DC signal is the > probi

Re: [beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2013-12-05 Thread Lei Wang
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 ...

Re: [beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2013-12-05 Thread Lei Wang
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 prob

Re: [beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2013-12-04 Thread dekrueg
On Wednesday, December 4, 2013 1:45:02 PM UTC-5, lisarden wrote: > > The abstract from the TPS65217 datasheet to describe what is going on here: > > 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

Re: [beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2013-12-04 Thread Maxim Podbereznyy
The abstract from the TPS65217 datasheet to describe what is going on here: 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 an

Re: [beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2013-12-03 Thread dekrueg
On Tuesday, December 3, 2013 12:32:03 PM UTC-5, Lei Wang wrote: > > Follow your finding on the unexpected TPS65217C behavior, I patched the > tps65217 driver with irq handling. The 3.2 kernel does not handle > nNMI/PMIC_INT interrupt; the 3.8 kernel does. I placed printk in the > interrupt hand

Re: [beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2013-12-03 Thread Maxim Podbereznyy
By the way when I connected 5vdc directly to the additional ldo ic I have grounded Vusb as well and the board worked without any reboot issue during 1 week. Probably I was in a wrong direction thinking that it was totally depending on the current overload at tps65217. One of the ideas was about the

Re: [beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2013-12-03 Thread Lei Wang
Follow your finding on the unexpected TPS65217C behavior, I patched the tps65217 driver with irq handling. The 3.2 kernel does not handle nNMI/PMIC_INT interrupt; the 3.8 kernel does. I placed printk in the interrupt handler and got the same result as yours. The PMIC_INT was issued every 2 seco

Re: [beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2013-11-27 Thread ancebfer
I have soldered a 15 ohm power resistor between SYS_5V (P9.8) and DGND (P9.2). This increases SYS_5V load by 333mA. After three days of test I can confirm that random reboot frequency have not changed so it seems that the current load is not the problem. BTW: I have found and unexpected TPS6521

[beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2013-11-21 Thread Antonio Cebrián
I have captured a BBB A5B random reboot with the oscilloscope (see attached image). Ch1 → VDD_3V3B (P9.4) Ch2 → VDD_5V (P9.6) Ch3 → SYS_5V (P9.8) Ch4 → SYS_RESETn (P9.10) This confirms that the random reboot is produced by 1 second SYS_5V fall. Best regards. 2013/11/20 > After readi

Re: [beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2013-11-21 Thread Maxim Podbereznyy
I don't think that connecting a USB cable reduces the current load to the PMIC because there are two different switches in the power path for the AC and USB inputs. They can't be opened at the same time because the PMIC can't be sure that two sources have the same voltage. If both switches are open

[beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2013-11-21 Thread peternadams
My guess is that some piece of the kernel is setting PWR_EN low (see pages 15 & 16 in the TPS65217 Datasheet). This would explain the 1 second duration of the off state. The system could restart due to PWR_EN floating high. It does not explain why connecting to the USB power prevents the random

Re: [beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2013-11-21 Thread Maxim Podbereznyy
I doubt the issue is connected with the floating nRESET pin. If you have a look at the "Figure 1. Global State Diagram" at page 16 the PMIC always waits for 1 second after a *FAULT*. Please read the following: FAULT = UVLO || OTS || PGOOD low|| PWR_EN pin not asserted within 5s of Wakeup event. If

[beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2013-11-21 Thread Lei Wang
Thanks for sharing the captured trace. It is very helpful. I wonder if you could further zoom in on the falling edge. I am really interested in the order of SYS_5V voltage drop and SYS_RESETn voltage drop. Also I noticed in TPS65217 datasheet, if the nRESET pin is pulled low, there will be a m

[beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2013-11-20 Thread ancebfer
After reading the Jakub thread the new conclusion is that this seems to bee a hardware related problem (related to PMIC). This may explain why changing kernel or changing CPU frequency doesn't resolve the problem (only minimizes it). I will test the Jakub hardware workaround (external MOSFET)

[beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2013-11-20 Thread Lei Wang
It seems that Angstrom 3.8 kernel is more robust. But I couldn't confirm that it will resolve the random reboot issue. I haven't done long term testing. I remember seeing someone also has problem with it. It could be just that kernel is more optimized which draws less current. Limiting the CPU

[beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2013-11-20 Thread ancebfer
I confirm that I have the same issue with a BBB A5B using TI 3.2 kernel. After reading the full thread I guess that the posible workarounds are: - Using Angstrom 3.8 kernel. - Powering the BBB from USB. - Limiting the CPU frequency. Can anybody confirm it? Best regards. El martes, 12 de novie

Re: [beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2013-11-19 Thread Illutian Kade
It could be a power 'level' issue. Most modern sound systems have a built-in kill switch. That if the volume spikes the speakers are turned off to prevent damage.. A similar system is probably in the BBB that prevents it from *receiving* to much power. It has to be something like that because o

Re: [beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2013-11-18 Thread Lei Wang
I think Robert is correct. I fetched a snapshot of u-boot (2013.10), build and dropped it in. It seems that the time jump problem is going away. I also did some testing with TI's kernel. I disabled the OPPs at 1G, 720M, and 600MHz. So the highest OPP is 500MHz. It seems that BBB is running much

Re: [beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2013-11-12 Thread Robert Nelson
On Tue, Nov 12, 2013 at 8:37 AM, wrote: > I have similar issue. I have (2) versions of BBB (A5A and A5C). They both > randomly reboot themselves while I am running TI prebuilt BBB android image > (from a couple hours to ten to fifteen hours). When I plug in the USB (DC is > still powered) for log

[beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2013-11-12 Thread lei6625
I have similar issue. I have (2) versions of BBB (A5A and A5C). They both randomly reboot themselves while I am running TI prebuilt BBB android image (from a couple hours to ten to fifteen hours). When I plug in the USB (DC is still powered) for logging with logcat, the reboot issue seems to di

[beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2013-10-31 Thread Illutian Kade
And now the board won't power on from the Debug Port, but will form the DC jack. At this point I'm about to say "fuck this shit". On Saturday, October 5, 2013 7:12:06 AM UTC-4, Illutian Kade wrote: > > Has anyone experienced their BBB rebooting at random? > > It was running solid for two days str

Re: [beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2013-10-29 Thread Illutian Kade
That's a bit of a relief. On Tuesday, October 29, 2013 8:35:38 AM UTC-4, lisarden wrote: > > You will not burn the board but Nothing will change because when powering > the board by a usb port the software limits the current to some level and > when this limit is exceeded then the board reboots.

Re: [beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2013-10-29 Thread Maxim Podbereznyy
You will not burn the board but Nothing will change because when powering the board by a usb port the software limits the current to some level and when this limit is exceeded then the board reboots. Therefore even if you give 100A to the usb port the pmic will limit it 29 окт. 2013 г. 9:47 пользов

Re: [beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2013-10-29 Thread kavitha bk
Good you know the reason But It is always better if you print your PMIC last boot status during next boot or even the Processor last boot reason so that next boot you can see the reason for reboot https://android.googlesource.com/kernel/omap.git/+/android-omap-tuna-3.0-ics-mr1/arch/arm/mach-omap2/r

Re: [beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2013-10-28 Thread Illutian Kade
Ya, figured it was something wrong with the port. The AC Adapter works fine; 5.1v on a meter. The board works fine; when powered by USB using the Debug Port. I wonder if I can use a 5v,2a "Fast Charger" port or if it'll burn out the BBB's Debug Port On Monday, October 28, 2013 9:10:19 AM U

Re: [beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2013-10-28 Thread Gerald Coley
That would be a first! I suspect it may be a grounding issue. Gerald On Mon, Oct 28, 2013 at 7:45 AM, Illutian Kade wrote: > UPDATE > > Appears the DC port on the board failed. > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are su

[beagleboard] Re: [Issue] BeagleBone Black Random Reboot

2013-10-28 Thread Illutian Kade
UPDATE Appears the DC port on the board failed. -- 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 beagl