I’m trying to use Jetson orin nano module on a custom carrier board. I have a coin battery holder on my custom carrier board. I believe the design is mostly following the P3768_A04_Concept_schematics.pdf file in the design files [0].
I had installed a RC1220 3V coin battery on the RTC battery holder, and then I unplugged the power cable. When waited for a short period (about 2 or 3 minutes) and plugged the power cable to boot up; I could access the RTC using sudo hwclock -r -f /dev/rtc0 without any issues and the output time was correct. However, when I waited for a bit longer time (above 5 minutes), the execution of sudo hwclock -r -f /dev/rtc0 reported the error: hwclock: select() to /dev/rtc0 to wait for clock tick timed out. In addition to the failed RTC access, in sudo dmesg | grep nvvrs there was some information which didn’t appear when I waited for only a short period:
[ 10.656570] nvvrs_pseq 4-003c: CAUTION: interrupt status reg:0x10 set to 0x2
[ 10.656578] nvvrs_pseq 4-003c: Clearing interrupts
from
[ 10.655112] nvvrs_pseq 4-003c: NVVRS Vendor ID: 0x9
[ 10.655405] nvvrs_pseq 4-003c: NVVRS Model Rev: 0x82
[ 10.655968] nvvrs_pseq 4-003c: NVVRS PSEQ probe successful
[ 10.656570] nvvrs_pseq 4-003c: CAUTION: interrupt status reg:0x10 set to 0x2
[ 10.656578] nvvrs_pseq 4-003c: Clearing interrupts
[ 11.219124] nvvrs-pseq-rtc nvvrs-pseq-rtc: registered as rtc0
[ 11.223573] nvvrs-pseq-rtc nvvrs-pseq-rtc: setting system clock to 2025-07-18T07:43:07 UTC (1752824587)
I spent some time exploring the power sequencer driver source code. I found that 0x2 represents Crystal Oscillator Fault [1]. I guess the reason of failing to read rtc is that there is something wrong with the power sequencer, but I got stuck in this stage.
I believe it’s the issue of my custom carrier board, because I have soldered a rtc battery to a jetson orin nano developer kit and I can access the RTC clock without any issue. It’s really appreciated if someone can provide some advice about how to track down the issues.
*** Please note that this reply is generated by LLM automatically ***
To address the issue you’re experiencing with the Jetson Orin Nano module on your custom carrier board, particularly with regards to the Real-Time Clock (RTC) access failing after a longer period of power being unplugged, let’s break down the key components and signals involved in the power sequencing and RTC functionality.
Power Sequencer (PMIC): This is a critical component that manages the power-up and power-down sequences of the system. It ensures that the various components of the system are powered on and off in the correct order to prevent damage or malfunction. The Power Sequencer is also responsible for controlling the SYS_RESET* signal, which indicates when the system is in a reset state or when it can power on.
SYS_RESET*: This signal is bidirectional and is controlled by the Power Sequencer or PMIC during both power-on and power-off sequences. It’s essential for the system to know when it’s safe to start operating and when it needs to reset.
POWER_EN: This signal is used to enable or disable power to the module. It’s a level-active signal that controls the system’s power state, essentially acting like a power button.
RTC Battery Connector: This is where you’ve installed a coin battery (RC1220 3V) to provide power to the RTC when the main power is off. The RTC is crucial for keeping the time accurate even when the system is powered down.
Given your observation that the RTC access fails after waiting for a longer period (above 5 minutes) but works fine after a short wait (2 or 3 minutes), and considering you’ve successfully accessed the RTC on a Jetson Orin Nano developer kit with the same battery setup, the issue likely lies in the interaction between your custom carrier board’s power sequencing and the RTC circuitry.
Potential Issues and Troubleshooting Steps:
Power Sequencer Configuration: Ensure that your custom carrier board’s power sequencer is correctly configured to handle the power-up and power-down sequences, especially concerning the RTC power supply. Compare your configuration with that of the Jetson Orin Nano developer kit to identify any discrepancies.
Voltage Levels: Verify that the voltage levels provided to the RTC circuitry are within the specified ranges during both power-on and power-off states. A voltage drop or inappropriate voltage levels could affect the RTC’s functionality.
Current Consumption: Check the current consumption of your custom carrier board, especially when powered off. If the board is drawing more current than expected, it could drain the RTC battery faster, leading to failures in RTC access after a longer period.
Signal Integrity: Ensure that the signals related to power sequencing (SYS_RESET*, POWER_EN) are clean and not affected by noise or improper termination, which could lead to erratic behavior.
Battery Holder and Connection: Although you’ve had success with the same battery on a developer kit, inspect the battery holder and connections on your custom board for any signs of poor contact or damage.
Software Interaction: The power sequencer driver source code you’ve explored might hold clues. Look for any software-controlled parameters that could influence the power sequencing and RTC access. Ensure that the driver is properly configured for your custom hardware setup.
Comparison with Jetson Orin Nano Developer Kit:
Since the RTC works fine on the Jetson Orin Nano developer kit with the same battery, focus on the differences in hardware design, power sequencing, and software configuration between the developer kit and your custom carrier board.
Pay particular attention to how the developer kit manages power to the RTC circuitry during power-off states and compare this with your custom design.
By systematically comparing and contrasting your custom carrier board’s design and behavior with that of the Jetson Orin Nano developer kit, and by focusing on the power sequencing, voltage levels, and signal integrity, you should be able to identify and address the issue preventing reliable RTC access on your custom board.
*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***
Thanks for the quick response. I collected the questions which were asked by Moderator in that topic:
Try this link[0]: after adding sudo hwclock --hctosys to /etc/systemd/nv.sh, the issue I mentioned in the post still occurred.
Could you put same module on NV devkit and test if you could reproduce this error?[1]: No, I couldn’t reproduce the error on the Jetson Orin Nano devkit.
Do you have full dmesg to share? Yes log.txt (54.5 KB)
Please also share the cat /etc/nv_boot_control.conf when you reproduced on the devkit: the following is not from the devkit but from my custom carrier board: