Involuntary reseting of the BBBlack.

[Jakub]

Hello!

I have a problem. It is based on an involuntary resetting of the BBBlack.

This happens occasionally. About once a day. Totally when you least expect it.

This happens more often on higher frequencies ( 800Mhz, 1Ghz).

On the console at the time of reset, nothing extra is displayed. No error's about kernel panic, sync, segmentation fault or another. 

Just like the same as if I pressed the reset button located on the board - but I DIDN'T!

I'm working on Koenkoi's linux-kernel ti33x-psp-3.2.28-r16c-gitr720e07b4c1f687b61b147b31c698cb6816d72f01 + a few changes to run on the BBB.

https://github.com/koenkooi/linux/archive/linux-ti33x-psp-3.2.28-r16c+gitr720e07b4c1f687b61b147b31c698cb6816d72f01.zip

Kernel is exactly the same as in the Angstrom release.

I would add, that on the BBW nothing bad happens, everything is working properly.

Anyone has already had a similar situation?

If it is necessary I can send the kernel patch and configuration file.

Best regards!

I look forward for suggestions!

Jakub.

[Jakub Żymełka]

I powered the board via pins 5 and 6 - VDD_5V on P9 connector. 

The BBBlack is as a module on the motherboard.

On the motherboard is a 5V power supply, realized according to the wiring diagram in attachment.

Have You any suggestions?

Best regards,

Jakub.

W dniu środa, 23 października 2013 15:33:10 UTC+2 użytkownik Gerald napisał:

How are you powering the board?

Gerald

--
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/groups/opt_out.

[Jakub Żymełka]

There are no hints or any solutions...??

Please help!

[Lei]

I have the same problem with BBB running Android. I tested TI prebuilt Android JB4.2 image. We have two versions of BBBs (A5A and A5C). Both of them have the issue. 

I posted my question on Ti e2e website: http://e2e.ti.com/support/embedded/android/f/509/p/297726/1049885.aspx#1049885

However it seems that the problem goes away when I load Angstrom image (based on 3.8 kernel). Also if I use Andrew Henderson's Android image (also 3.8), the problem goes away. However we cannot use Andrew's image since there are a lot drivers are missing. 

I also have the time jump forward problem. The problem goes away when I switch to 3.8 kernel.

Jakub, may I ask what version is your BBB?

Lei

[Jakub Żymełka]

My BBB is A5C version. We've tested more than 10 pcs BBB and all of it has the same problem...

One, but not very elegant solution is to after start the board, make a jumper between pins SYS_5V and VDD_5V, in example with any mosfet transistor.

With this jumper, on kernel 3.2 there was no reset from the time of three weeks.

Anybody have any other solutons? Because this cannot be the final.

Best regards!

I look forward for suggestions!

Jakub.

[Lei Wang]

The time jumping issue seems to relate to u-boot per Robert Nelson's suggestion (https://groups.google.com/forum/#!category-topic/beagleboard/beaglebone-black/xPxzYyNsA78). I dropped in a newer u-boot images. It seems to fix the problem.

For the random reboots, I limited the CPU clock frequency to 500MHz. It seems that the board is running more robust. So far I didn't see any random reboot. However I still don't understand why it seems that Angstrom or 3.8 Android images make the difference.

Connect SYS_5V and VDD_5V? Since I noticed by connecting the board to a USB port (i.e. adb) seems to stop the random reboot, I wonder if it has something to do with VDD_5V and SYS_5V. I will do a little bit more digging into the schematic. 

For test purpose can I just use a wire to connect SYS_5V and VDD_5V after boot up? 

Thanks!

Lei

[Maxim Podbereznyy]

this issue can probably be because tps65217 simply can't handle too much current through a single pin. If an internal switch AC|USB=SYS get overheated then it can just shutdown to avoid a system damage

2013/11/19 Lei Wang <lei...@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/groups/opt_out.

--

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

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

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

[Jakub Żymełka]

Lei Wang, 

yes, You can just use a wire to connect SYS_5V and VDD_5V after boot up.

We've done this before we choose the option with the transistor.

We are working on the 04.2013 U-boot, so we will try the newest version 10.2013 and I will let you know about my results.

lisarden,

According to you, the power management unit ( tps65217 ) in the BBB is not able to provide enough power by single pin?

So why in the BBWhite or with the 3.8 kernel is no any random reboot? The PMIC is exactly the same...

[Maxim Podbereznyy]

Jakub, answering to your question:
tps65217b is not tps65217b (bbb)
Bbw 600mhz vs bbb 1000mhz
Ddr2 pwr consumption != ddr3

That is why when people reduce the cpu freq systems become stable, but I don't think it can help because I run my board in cpu ondemand governor and it still reboots. However when running ezsdk my system seems to be stable while on Ubuntu it reboots randomly

20 нояб. 2013 г. 10:53 пользователь "Jakub Żymełka" <zymelk...@gmail.com> написал:

[Jakub Żymełka]

Ok, I see.

But tps65217C (in BBB) has a more power availability vs. tps65217B (in BBW).

Reducing the CPU speed is not the solution. For example I would like to work with a clock speed of 1GHz.

So, are You suggesting that the PMIC is incorrect?

Can anyone else give an opinion? Maybe the designers of the new BBB?

Best regards,

Jakub.

[Maxim Podbereznyy]

Can you prove it? You mean it can supply more current? :)

> But tps65217C (in BBB) has a more power availability vs. tps65217B (in BBW).

2013/11/20 Jakub Żymełka <zymelk...@gmail.com>

[Jakub Żymełka]

On the TI product page http://www.ti.com/product/tps65217B#feature is the information about current limit:

"Two Independent Load Switches That Can Be Configured as LDOs

Configured as LDOs:

- LDO Output Voltage Range: 1.5 V – 3.3 V

- VIN Range: 2.7 V – 5.8 V

- 200-mA Current Limit (TPS65217A, B)

- 400-mA Current Limit (TPS65217C, D)"

Or maybe i'm wrong? 

[Maxim Podbereznyy]

Ldo3 and ldo4 are not used to power any of really current- hungry unit like the ddr3 or the cpu core.

20 нояб. 2013 г. 13:23 пользователь "Jakub Żymełka" <zymelk...@gmail.com> написал:

[Maxim Podbereznyy]

Hey guys!

I'm pretty sure that this mail-list is also read by people who are invloved into kernel development and they may be aware of why 3.8 does not reboot and 3.2 (TI) reboots the BBB. Are they here and can surmise where the issue is?

2013/11/20 Maxim Podbereznyy <lisa...@gmail.com>

[rod calabio]

There was a note on Beaglebone Black that the newest version   BBB version 6  has or'd the reset button and the power button to prevent a reset, now whether or not it is the same problem

as posted originally, ho knows.  But I had the same issue where I was ssh'd into the BBB for several hours and then it just stopped for no reason.

[Gerald Coley]

That is not what it was for. It was to prevent a premature loss of reset during power up.

Gerald

[Maxim Podbereznyy]

Hey guys!

If anyone still experiences the unexpected reboot issue I've found another solution to avoid it: raise the pin 2 (unconnect it from a pcb pad) of TL5209 (soic-8 chip) and solder a wire between this pin and 5V supplied from a wall adapter. TL5209 feeds mostly the Ethernet PHY and sometimes the PHY consumes to much current that is not possible to pass through tps65127. I really don't have any theory about it but this solution proves 100% its viability. Applied to my board and it worked during 96 hours and I even heated it by a hair fan to 70 Celsius degrees and it worked just as expected. Of course this solution works only if you use 5VDC source, not USB power. Another pros is that you only need a wire and a soldering tool, while the solution with a MOSFET requires a lot more precise soldering and the MOSFET itself.

2013/11/22 Gerald Coley <ger...@beagleboard.org>

[Gerald Coley]

Hmmmm. 

Gerald

[Lei Wang]

I think I've found the cause and a workaround.

It seems that the PMIC is somehow confused by USB-OTG probing since it is detecting USB VBus signal and the am3359 is probing the same pin.

Once I disabled the USB-OTG (see the link below for the code change), the system is running without problem.

On the other hand, I notice there is no USB-OTG probing signal on kernel 3.8 ( for both Angstrom and Andrew's Android port). That may explains why the 3.8 kernel does not seem to have this behavior.

Furthermore, if USB is connected on the mini connector, the probing is stopped. That also makes the random reboot problem going away.

If the USB-OTG is not required, the workaround should be worth a try. 

Also I wonder something needs to be done on the Beaglebone black design to prevent this happening, or perhaps TI's fellows should take a look at the logic in the PMIC (TPS65217C) design. 

Please let me know the test result.

Thanks.

https://groups.google.com/forum/#!category-topic/beagleboard/beaglebone-black/xPxzYyNsA78

[Gerald Coley]

The port is not an OTG port and does not support OTG functionality. It is only a client port. The PMIC was not designed for an OTG port. It expects to see a host port from the PC. That is why OTG probing is not in the kernel we created for the BeagleBone Black.

Gerald

[dickelbeck]

The boards will reboot if :

a) OTG is disabled in the kernel build, and
b) g_multi.ko is loaded, and
c) the usb cable is disconnected.

If you remove b) then they stay up.

This is with kernel 3.12.9

[Gerald Coley]

How are you powering the board?

Gerald

On Wed, Oct 23, 2013 at 6:09 AM, Jakub <zymelk...@gmail.com> wrote:

--