When using the TSC function to output PWM signals, we occasionally find that after setting the PWM frequency, we need to wait for a few seconds before the PWM signal is output. This issue occurs with a low probability, but once it occurs, it persists and requires a restart to return to normal.
When the issue occurs, we captured the following signals:
*** Please note that this reply is generated by LLM automatically ***
The issue you’re experiencing with the TSC function outputting PWM signals on the Jetson AGX Orin series seems to be related to the power management and sequencing of the module.
According to the provided context, the Jetson Orin NX and the product carrier board must be power sequenced properly to avoid potential damage to components on either the module or the carrier board system. The power sequencing steps between the carrier board and Jetson Orin NX are determined through a set of control signals, including the SYS_RESET* signal.
During power up, the carrier board must wait until the signal SYS_RESET* is deasserted from the Jetson module before enabling its power. The Jetson module deasserts the SYS_RESET* signal to enable the complete system to boot.
It’s possible that the issue you’re experiencing is related to the power sequencing and the timing of the SYS_RESET* signal. The fact that the issue occurs with a low probability and persists until a restart is performed suggests that it might be related to the power management and sequencing of the module.
To troubleshoot this issue, you may want to investigate the power sequencing and timing of the SYS_RESET* signal on your carrier board. You can refer to the Jetson Orin NX Series Product Design Guide for system level details on the application of power, power sequencing, and monitoring.
Additionally, you can try to use the power management tools and techniques provided by NVIDIA, such as the nvpmodel GUI and the Jetson Power GUI, to monitor and control the power consumption of your module. These tools may help you to identify the root cause of the issue and find a solution.
In comparison, the Jetson Orin NX Series and Jetson Orin Nano Series have similar power management features, but the specific implementation and timing of the power sequencing signals may differ. Therefore, it’s essential to consult the specific documentation for your module and carrier board to ensure proper power sequencing and to troubleshoot any issues that may arise.
In summary, the issue you’re experiencing with the TSC function outputting PWM signals on the Jetson AGX Orin series is likely related to the power management and sequencing of the module. Investigating the power sequencing and timing of the SYS_RESET* signal, and using the power management tools and techniques provided by NVIDIA, may help you to identify the root cause of the issue and find a solution.
*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***
am using the Jetson AGX Orin development kit.
Hi yanxiao,
What’s the Jetpack version in use?
Is the delay about 4.5s as shown in your image?
Please share the steps how did you reproduce this on the devkit.
Is there the similar delay if you just simply enable a PWM output?
We are using Jetpack 6.2. The delay is 4.5 seconds as shown in my picture. Without restarting the device, this delay persists and remains around 4.5 seconds. The system can return to normal after a restart, but the delay does not occur every time. When the issue arises again, the delay may range from a few seconds to dozens of seconds.
It occurs occasionally, and we have not found a pattern to reproduce it.
We have found that if we first power on the platform and let the camera stream data for a period of time (ranging from several hours to more than ten hours) before enabling the TSC to generate PWM signals, the probability of delay occurrence becomes higher. Once the delay occurs, it will persist.
But it does not occur every time after the device is powered on.
We modified the TSC function with reference to cam_cdi_tsc.c.
Do you mean that the issue occurs after you customize the cam_cdi_tsc.c?
Or modifying this driver can help for the current issue?
This issue occurred after we modified cam_cdi_tsc.c. We are not sure whether the issue would occur if we did not modify cam_cdi_tsc.c. The modified code is as follows:
obc_cam_sync.txt (13.0 KB)
I would suggest you just revert the driver to original.
Please help to clarify what customization may cause current issue.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
