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.
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ł:
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.
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.
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.
W dniu piątek, 8 listopada 2013 05:12:08 UTC+1 użytkownik Lei Wang napisał:
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?
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
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…
W dniu wtorek, 19 listopada 2013 20:05:34 UTC+1 użytkownik lisarden napisał:
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
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.
W dniu środa, 20 listopada 2013 08:42:18 UTC+1 użytkownik lisarden napisał:
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?
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.
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.
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.
