[JP6.2]RTC clock read timout on NVIDIA Orin

Robotics & Edge Computing Jetson & Embedded Systems Jetson AGX Orin
1

After longer time of running system. I’m not able to read or write to rtc0 clock. When I try read using hwclock command result is:

sudo hwclock -r
hwclock: select() to /dev/rtc0 to wait for clock tick timed out

sudo dmesg|tail
[ 3792.198076] nvvrs_pseq 4-003c: CAUTION: interrupt status reg:0x10 set to 0x8
[ 3792.198095] nvvrs_pseq 4-003c: Clearing interrupts
[ 3808.196630] nvvrs_pseq 4-003c: CAUTION: interrupt status reg:0x10 set to 0x8
[ 3808.196648] nvvrs_pseq 4-003c: Clearing interrupts
[ 3861.191233] nvvrs_pseq 4-003c: CAUTION: interrupt status reg:0x10 set to 0x8
[ 3861.191253] nvvrs_pseq 4-003c: Clearing interrupts
[ 3907.187668] nvvrs_pseq 4-003c: CAUTION: interrupt status reg:0x10 set to 0x8
[ 3907.187688] nvvrs_pseq 4-003c: Clearing interrupts
[ 3971.181845] nvvrs_pseq 4-003c: CAUTION: interrupt status reg:0x10 set to 0x8
[ 3971.181863] nvvrs_pseq 4-003c: Clearing interrupts

I’m using Jetpack 6.2.

2

*** Please note that this reply is generated by LLM automatically ***

Based on the provided context, I’ll try to help you troubleshoot the issue with reading or writing to the rtc0 clock.

Firstly, I’d like to clarify that the context doesn’t explicitly mention rtc0 clock or hwclock command. However, I can try to provide some general guidance on clock-related issues on Jetson devices.

Since you’re using Jetpack 6.2, I’ll assume that you’re running a Linux distribution on your Jetson device. The context mentions Jetson Linux, which is a Linux distribution for NVIDIA Jetson modules and developer kits.

One possible reason for the issue could be related to the clock settings or configuration. The context mentions PLL_C, PLLAON, and CAN clocks, but it’s not clear if these are directly related to the rtc0 clock.

To troubleshoot the issue, you can try using the jetson_clocks command to show the current clock settings:

jetson_clocks --show

This command might provide some insights into the current clock configuration.

Additionally, you can try storing the current clock settings using the jetson_clocks --store command. This might help you identify if there are any changes to the clock settings that could be causing the issue.

If you’re experiencing issues with reading or writing to the rtc0 clock, it’s possible that there’s a problem with the clock’s parent clock or the clock’s configuration. The context mentions that the PLLAON clock is disabled by default on Jetson devices with T194 processors, but it’s not clear if this is related to the rtc0 clock.

To enable PLLAON, you would need to modify the BPMP firmware DTB and kernel DTB files, as described in the context. However, this might not be directly related to the rtc0 clock issue.

If you’re still experiencing issues, you might want to try using the RTRACE tool to determine if there are any register access issues before a reset or panic. This could help you identify if there’s a problem with the clock’s configuration or if there’s a hardware issue.

To enable RTRACE, you would need to add the CONFIG_PSTORE_RTRACE=y and CONFIG_PSTORE_RTRACE_ENABLE_AT_STARTUP=y settings to the kernel configuration.

In summary, I would recommend trying the following steps to troubleshoot the issue:

  1. Run jetson_clocks --show to display the current clock settings.
  2. Run jetson_clocks --store to store the current clock settings.
  3. Check if the PLLAON clock is enabled or disabled, and consider modifying the BPMP firmware DTB and kernel DTB files if necessary.
  4. Use the RTRACE tool to determine if there are any register access issues before a reset or panic.

If none of these steps resolve the issue, please provide more information about the error message you’re seeing when trying to read or write to the rtc0 clock, and I’ll try to help you further.

4

Answer is not helpful.

5

How long to reproduce the problem? Any specific APP/tools to run?

6

After booting the device, the /dev/rtc0 clock value must be modified using the hwclock command multiple times (minimum 3-4 times). Subsequently, a longer waiting period is required, approximately 20-30 minutes, sometimes up to an hour. After this elapsed time, attempting to modify the time value again results in an interrupt error.