Tegra_bccplex_watchdog

My jetson xavier AGX reboots about once every few days. “### PMC reset source:” in syslog is recorded as “TEGRA_BCCPLEX_WATCHDOG”.

By the way, when watchdog is used by the following command, it seems that “TEGRA_SOFTWARE_RESET” is recorded in “### PMC reset source:”.
echo 1> / dev / watchdog

So I have a question.
1: When is it rebooting with TEGRA_BCCPLEX_WATCHDOG?
2: How can I avoid it?

note)
a} The version of SDK I’m using is:
R32 (release), REVISION: 3.1, GCID: 18186506, BOARD: t186ref, EABI: aarch64, DATE: Tue Dec 10 07:03:07 UTC 2019
b} There is no clue in the serial console log, and suddenly a reboot occurs as shown below.

W> RATCHET: MB1 binary ratchet value 4 is too large than ratchet level 2 from HW fuses.
I> MB1 (prd-version: 1.5.1.2-t194-41334769-9ec1833d)

If the cpu gets hang over timeout, watchdog will trigger this reboot and next reboot reason will be TEGRA_BCCPLEX_WATCHDOG.

As for why the cpu would hang may have lots of reasons. Better using the uart console to monitor the log. For example, what are the last few lines running before the reboot.

Thank you for your answer.

For example, what are the last few lines running before the reboot.

There are no clue in syslog,console log.
Attach the log.
console_part.log (43.4 KB)
syslog_part.log (95.6 KB)

It looks like a custom board. Is there any application running before it goes to reboot?

Yes. I always run 1080p recording and playback applications on gstreamer.
It looks like there is no bad behavior in the logs on gstreamer.
Does this condition occur due to malfunction of encoder and decoder?

Is it possible to do the same test over the devkit and see if issue is still?

If this is software problem then similar case shall happen on devkit too.

When does xavier reboot with TEGRA_BCCPLEX_WATCHDOG without leaving anything in both syslog and consolelog?

Such error is case by case. It is unlikely to just know why the reboot reason is TEGRA_BCCPLEX_WATCHDOG and no log got recorded.

Please also check

/sys/fs/pstore/console-ramoops-0

or

/sys/fs/pstore/dmesg-ramoops-0

after the error happened and see if any log there. Also, please move to devkit to debug. This is our standard process here.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.