We have a custom carrier board that supports xavier-nx. Shutdown works correctly, i.e. pin 233 goes low after sudo poweroff.
Now, we have done some modifications to the orin-nano device tree so that it would work on the same carrier board. Everything is okay except for the shutdown. In particular, systemd prints shutdown and the CPU goes idle (observed on the serial cable), however, pin 233 is still on high. And about a minute or two later, it boots back up because the power-on signal (pin 237) is still high since our power sequencer did not see the low voltage on the SHUTDOWN_REQ* pin.
We have probed SHUTDOWN_REQ* pin with an oscilloscope and there was no change in the voltage (no dip).
We are using the default pinmux for shutdown_n (aka SHUTDOWN_REQ*/pin 233) in both mb1 bct and kernel. And we are on jetpack 5.1.5 with r35.6.1.
*** Please note that this reply is generated by LLM automatically ***
Based on the provided context, I will attempt to provide a comprehensive answer to the question.
The issue described is related to the shutdown functionality on a custom carrier board for the Jetson Orin Nano module. The shutdown process is initiated correctly, but the SHUTDOWN_REQ* pin (pin 233) does not go low, causing the power sequencer to not detect the shutdown request. As a result, the system boots back up after a minute or two.
To troubleshoot this issue, let’s analyze the relevant information from the provided context:
Module ID Pin: The Module ID pin (Pin 217) is used to determine if the module is a legacy module or an advanced module. However, this is not directly related to the shutdown functionality.
Power Down Initiated by SHUTDOWN_REQ Assertion*: Figure 6-5 shows the power down sequence initiated by the SHUTDOWN_REQ* assertion. The SHUTDOWN_REQ* pin is driven by the Power Sequencer or PMIC during power down. However, in this case, the SHUTDOWN_REQ* pin is not going low.
Power Button Supervisor MCU Power-On: The Power Button Supervisor MCU Power-On is related to the power button functionality, which is not directly related to the shutdown issue.
Secure Boot Process: The secure boot process is related to the authentication and verification of the UEFI image. However, this is not directly related to the shutdown functionality.
Considering the provided information, here are a few potential causes for the issue:
Incorrect Pinmux Configuration: Although the default pinmux configuration is used for the SHUTDOWN_REQ* pin (pin 233) in both mb1 bct and kernel, it’s possible that there is an issue with the pinmux configuration. Verify that the pinmux configuration is correct and consistent across all configurations.
Signal Integrity Issue: The SHUTDOWN_REQ* pin is not going low, which could be due to a signal integrity issue. Verify that the signal is not being pulled up or down by any other component on the carrier board.
Power Sequencer Configuration: The power sequencer is not detecting the shutdown request, which could be due to a configuration issue. Verify that the power sequencer is configured correctly to detect the SHUTDOWN_REQ* signal.
Software Issue: The shutdown process is initiated correctly, but the SHUTDOWN_REQ* pin is not going low. This could be due to a software issue, such as a bug in the kernel or UEFI code. Verify that the software is up-to-date and that there are no known issues related to the shutdown functionality.
To further troubleshoot the issue, I would recommend:
Verifying the pinmux configuration and signal integrity of the SHUTDOWN_REQ* pin.
Checking the power sequencer configuration to ensure it is detecting the SHUTDOWN_REQ* signal correctly.
Reviewing the kernel and UEFI code to ensure that there are no known issues related to the shutdown functionality.
Using a logic analyzer or oscilloscope to verify the signal on the SHUTDOWN_REQ* pin during the shutdown process.
By analyzing the provided context and considering potential causes for the issue, I hope this answer provides a comprehensive and helpful response to the question.
*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***