Jetson T5000 GPIO Table PPS Input & Camera FRSYNC Input

Robotics & Edge Computing Jetson Systems Jetson Thor
1

Dear NV Support Team,

We are currently designing a carrier board for the NVIDIA Jetson T5000 module and need to confirm the GPIO assignment and capability for multi-sensor time synchronization signals. According to our hardware requirement, we need to assign GPIOs for:
Primary PPS Input → Pin J19 (GPIO67 / GP00)
Secondary PPS Input → Pin B55 (GPIO30 / GP02)
Camera FRSYNC Input → Pin F61 (VCOMP_ALERT_N / GP01)
However, after reviewing the available pinout and GPIO tables(Jetson_Thor_Series_Modules_Pinmux_Template_v1.7), we are unable to verify if these specific pins fully support these primary and secondary functions.Could you please assist us with the following questions?GPIO Functionality Verification: Can Pins J19, B55, and F61 support 2x PPS Inputs + 1x Camera FRSYNC Input simultaneously? If not, what are the primary and secondary supported functions/modes for these pins?Alternative GPIO Assignment: If the specified pins do not support these functions, could you recommend alternative pins on the Jetson T5000 connector for Dual PPS and Camera Frame Sync (FRSYNC)?Detailed Documentation Request: Could you provide the detailed Jetson T5000 Pinmux / GPIO Table (including pin definitions, default pinmux states, internal pull-ups/pull-downs, and supported primary/secondary SFR functions) to assist with our hardware schematic design?

Thx~

3

Hi johnny.yu,

What’s the Jetpack version in use?

Based on the current Jetson Thor pinmux table, J19, B55, and F61 are not recommended as a validated combination for 2x PPS inputs plus 1x Camera FRSYNC.

For PPS, please use HTE-supported GPIOs, preferably AON GPIOs validated for PPS/NVPPS.
For camera frame sync, please use the dedicated CAM_FRSYNC pins rather than F61.

Also, please refer to the latest pinmux spreadsheet version (v1.8 rather than v1.7), since newer revisions include updated CSI/control signal definitions.

4

Hi Kevin,

I have checked the v1.8 documentation, and it appears that the GTE-supported pinout should be compatible with our requirements. Could you please confirm if my understanding is correct?

If this is not the case, could you kindly provide more detailed documentation or technical specifications regarding GTE pinout support for v1.8?

圖片
圖片196×642 6.11 KB

Thx~

5

In the Picture, all of these pins support FRSYNC output. Do they require the corresponding FRSYNC input pin (GPIO37)?
圖片

6

Thanks for checking v1.8. GTE support does not by itself imply CAM_FRSYNC support. J19, B55, and F61 are GTE-capable, but they do not expose CAM_FRSYNC/TSC_EDGE_OUT in the v1.8 pinmux table.

For FRSYNC output, please use the pins with TSC_EDGE_OUT, such as GPIO17/CAM_FRSYNC1, GPIO42/CAM_FRSYNC2, and GPIO38/CAM_FRSYNC3. GPIO37 is also TSC_EDGE_OUT-capable, but it does not appear to be a required input for the other CAM_FRSYNC outputs in the table.

7

Hi @KevinFFF, just to clarify: this design is meant to loop back the FRSYNC output from Thor into a separate GPIO input pin in order to timestamp the edge of the looped back signal using GTE. J19, B55, and F61 are intended to be used as inputs to Thor, and not to drive FRSYNC itself. FRSYNC outputs will be driven by TSC_EDGE_OUT-marked pins like you said.

8

Thanks for the clarification.
Yes, this loopback approach should be applicable on Thor: use a TSC_EDGE_OUT pin for FRSYNC output, then loop it back to a GTE-capable AON GPIO input for edge timestamping.

In the Thor v1.8 pinmux table, J19/GP00, F61/GP01, and B55/GP02 are marked as GTE-capable, while GPIO17/GPIO42/GPIO38/GPIO37 expose TSC_EDGE_OUT options.
Please still validate with your final pinmux/device-tree/BSP configuration.