This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Beaglebone black rebooting unnecessarily

Other Parts Discussed in Thread: TPS65217

Hi, i have beaglebone black running jellybean OS(TI provided OS) and it has chipsee 7'' LCD touch display as gui. After using the board for long period of time i am facing weird issue that the OS reboots by itself. I am taking out UART pins and connecting external microcontroller. This rebooting problem is not at all solved even after flashing OS many a times onto the SDCard. Please suggest some solutions.  

  • Hi Kishore,

    Can you get a serial output to quickly see what has happened to reboot?

    It could be because of some of the critical android services exits or watchdog triggering or some hw connection issue.

    Regards,

    Arun

  • It seems that we have the same problem.

    We used TI prebuilt JB422 image for BeagleBone Black. I tested the image on (3) BBB boards (A5A and A5C versions). The configuration is very simple: output to an HDMI display and with a mouse connected. All (3) boards had the same behaviors. It rebooted itself randomly. Sometimes after a couple hours sometimes after 10 to 20 hours. I used a serial to USB cable to log the console output. It does not seem to be anything wrong. It just simply rebooted itself.

    I have tried different power supplies (3A to 6A) and also tried to a UPS. None of them seems to help. We need a stable android system so that we can continue our development. Right now we are stuck.

     

  • Hello,

    We have tested BeagleBoneBlack version A5A running TI_Android_JB_4_2_2_DevKit_4_1_1  overnight and could not observe the issue.

    If the device reboots it could be because either android is invoking reboot system call or could be a power disruption.

    Can you have the logcat command running to capture is something is failing in Android over the course of time?

    Regards,

    Arun

  • I've hooked up the USB adb to one of my BBB to logcat the activity. However once I hooked up the USB, the random reboot has not happened (during the last 68 hours). At the same time, I setup another BBB without adb. The reboot happened (5) times during the last 36 hours. Both BBBs exhibited random reboots behaviors before.

    Another strange behavior is that the clock of BBB jumps forward randomly. However each jump is around 2^17 seconds (about 36 hours 24 min). I wonder if the clock jumps are related to the random reboot or the other way.

    I tried the Angstrom image. The clock is working Ok and no random reboot observed. I tested Andrew Henderson's Android image (using 3.8 kernel). There is no random reboot and clock is Ok too. However I am not able to use it since lots of drivers are not available.

  • Hi Guys!

    It seems that I'm having a very same issue with beaglebone black. We have very good experience with beaglebone rev A6 so we moved on to black with a next generation gadget and jelly bean Android 4.2.2 with sitars SDK.

    I have two prototypes they have and expansion board with touch panel, LCD, WIFI and RFID attached, same as with previous models.

    Android boots up, I benchmarked it with Roboperf and oXbench as well and everything went really well.

    Then I left them for the weekend and monitored them for uptime etc...

    What I see that both of the devices are rebooting after a certain time. Both systems are in idle state connected to a WIFI hotspot. Logcat is redirected to file and there is nothing in it just wlan keyring change debug logs before reboot.

    There is nothing suspicious in:

    • /data/tombstones
    • /data/anr
    • /data/system/dropbox
    I will attach a copy of my several day persisted logcat but I think there is nothing in it. Of course I can't see anything in dmesg. BUT:
    Can I somehow trigger a dumpstate and/or dmesg redirect in file before system reboot. I'm just asking because the system recovers fine but I'm annoyed that I can't determine what is the cause of the reboot:
    • Memory leak?
    • HW issue?
    • Voltage issue?
    • Grounding issue?
    I would really at least like to know the reason of the reboot because we had 30 to 40 days uptime wilth the "good old" beaglebone rev a6
    Please guys we need to figure this out.
    In connection with original post, why aren't you just start logcat as me so you don't have to adb over USB you can check the file after reboot. I will also attach a reference init.rc so you can check how I'm making dir in data and starting logcat service after that.
  • It seems to me that my boards had a little different behavior. If I leave the USB adb cable pluged in, the board is more stable (not observing reboots). We wish with the new A6 BBB the reboot problem might be fixed, which may not be the case. Also it seems that the PMIC drops the SYS_5V when the reboots happen (see one of the links below). I also captured the same trace on my oscilloscope.

    I am not sure if this is the kernel behavior, which I am highly doubt. I placed debug code (printk) in the tps65217 driver at the lowest level where the kernel accesses the PMIC register. There is nothing printed out before the reboots from my console logs.

    I just took the look at the Beagleboard (BBW) schematic. The SYS_5V was connected very differently than for the BBB. On the BBW, the SYS_5V supplies the user LEDs and USB0 and USB1. It seems that SYS_5V is always stays On while SYS_VOLT is On. However on the BBB SYS_5V is supplying all DCDCs and LDOs.

    FYI, there are a few threads on Google BeagleBoard group discussing about the same issue:

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

    https://groups.google.com/forum/#!searchin/beagleboard/reset/beagleboard/5qSJ4dQdar4/rBKaUMOQDhsJ

    Please feel free to post to those threads too to share your findings and get more feedback.

     

     

     

  • Thanks for the answer Lei!

    I can just have the hope that this is a hw issue and will be fixed in new Rev A6 versions. We already ordered them and I will run some tests with the new setup.

    The annoying part is that I can't dump any logs. Based on your description you are monitoring much lower and if there is no log output at all this can be really a hw issue.

    Maybe this depends on the expansion peripherals too.

    I've read the linked articles and they describe the very same as I experienced here. System is running quite nice, all parameters seem to be OK, logcat has no errors, there is nothing beside the normal boot log in dmesg. I'm running RowboPerf and the experienced restart is just like I pressed the hw reset button... Very strange.

    I will get back to you after Rev A6 is tested.

    Best Regards,

    sodjas

  • Hi Guys!

    Some update, we tested Rev A6 and it rebooted as the previous, so I started thinking about what if there is nothing with the bone but the power quality.

    At first, I disassembled the power unit made by our supplier and realized there is a very low quality  AC/DC converter in it so I ordered a "normal" DC + put the whole configuration behind a UPS. Aaaand this system is running for 24 hours :)

    The next step will be to use it without the UPS if the uptime will be still above 24 hours to 36 hours then in our case the powering was not robust enough to keep the system running for a "bigger" amount of time.

    This is of course just our case, but I want to share my experience maybe this will be also a good hint for somebody building a similar system...

    So the summary in our could be that a robust DC supply should be made which swallows the periodical spikes that could cause a possible reboot.

    We have and expansion board with WIFI, LCD, touch panel and 2,3 further peripherals attached to the system.

    I'm not a electircian just a developer so sorry if some of the statements regarding power supplies are wrong, I will tell my supplier just in short to "make a more robust supply man" :)

    Best Regards,

    sodjas

  • Thanks for the update.

    There is some new information in regarding to the cause of BBB random reboot. It seems to relate to the unexpected behavior of tps65217c USB power status change detection. Details see the links below:

    http://e2e.ti.com/support/arm/sitara_arm/f/791/p/305879/1068971.aspx#1068971

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

  • I believe I've found a workaround.

    You need to disable the USB-OTG since its probing signals are causing the random reboots. Details please see the links below.

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

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

  • Hi Guys!

    It seems that this patch with the OTG disable solved the issue. My gadget was running all the weekend with the Rowboperf benchmark running in the foreground! :) So these are good news. BUT:

    I saw that the system time randomly jumps in the future and then is set back by NTP, could this be also some kind of interference issue? Had someone have a similar issue? : Here are some log examples attached.

    7713.timestamp.log

    Thanks,

    Best Regards

  • Just an update Guys, I started a separate thread for this time issue, and already had some great hints, the sys time thread continues here:

    http://e2e.ti.com/support/embedded/android/f/509/p/308616/1073987.aspx#1073987

    Cheers,

    sodjas

  • Hai

    I am really struggling with BeagleBone Random Re-Start issue.

    I found some work-arounds like

    1 ] Decrease the frequency

    2 ] Change the Kernal to version 3.8

    3 ] Powering the BBB from USB

    etc.

    Is there any patch available for disable the USB-OTG cable ? . What is the change regarding the PMIC in linux kernal version3.2 & kernal3.8

    How to solve this issue ? I am waiting for all great solutions & suggestions. Please reply me ASAP . Lot of thanks in advance.
  • Hi Don,

    The patch for the OTG functionality is linked here in the thread a few posts before by Lei Wang10. He posted two links and mentions the OTG.

    My experience is that if you grab the latest TI package the linux kernel should just be fine.

    Best Regards,
    sodjas
  • Dear Sodjas

    Lot of thanks for the quick reply .

    Could you please share me the link of patch file and link of latest kernal source from TI.

    I am waiting for your reply ?
  • This is the reply I mentioned, and this helped me, but it not means this is the solution too for your problem:

    I believe I've found a workaround.

    You need to disable the USB-OTG since its probing signals are causing the random reboots. Details please see the links below.

    You can set the USB functionality in board-am335xevm.c, this is what I changed:

    @@ -3956,7 +4124,7 @@ 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_PERIPHERAL,
            .power          = 500,
            .instances      = 1,

    Best Regards,

    sodjas

  • Dear Sodjas

    I have completed the code as per your suggestion.

    But some doubts still remaining ...


    In my BeagleBone(I am using BeagleBone White) USB A is Labeled as USB Host & Debugging port labeled as USB (Client) .

    Still i can enter into shell & Serial console via putty through the USB debugging port & i am able to connect USB mass storage device to the BeagleBone through USB A port.


    How can i ensure USB-OTG is disabled in my BeagleBone. I am a green-horn in the embedded development . Sodjas waiting for your great reply . . . . . . .

  • Dear Don,

    White bealge could be a slightly different to set up. I only had deeper exp. with the black. Maybe a TI employee could help you, that one liner form OTG to PERIPHERIAL helped me.

    You should compare the WITHE SRM with BLACK SRM maybe you will see the differences regarding USB config, I would go that way. 

    Best Regards,

    sodjas