I am currently working with a Jetson Orin NX (P3767-0004) running JetPack 6.1 on a custom carrier board.
The 40-pin expansion header on our board follows the same pin mapping as the Jetson Orin Nano / Orin NX developer kit.
Current Setup
I have successfully verified that UART1 is working correctly:
Pin 8 → UART1_TX
Pin 10 → UART1_RX
A loopback test between TX and RX works correctly using /dev/ttyTHS1.
Now I would like to use Pin 36 (UART1_CTS → PR.05) as a GPIO input for a button, since I am not using hardware flow control.
According to the pin mapping:
Pin 36 → UART1_CTS → GPIO3_PR.05
Pad register: 0x2430090
What I Observed
From Linux:
gpioinfo | grep PR.05
line 113: "PR.05" unused input active-high
Pad register:
sudo busybox devmem 0x2430090
0x00000055
UART configuration:
sudo stty -F /dev/ttyTHS1
speed 115200
(no crtscts enabled)
However, when I connect a button and try reading the pin:
gpioget gpiochip0 113
or
gpiomon gpiochip0 113
the value does not change when the button is pressed.
Question
Is it possible to use UART1_CTS (PR.05) on pin 36 of the 40-pin header as a GPIO input when UART1 is used only for TX/RX?
If yes, could someone please provide a step-by-step procedure for JetPack 6.x on how to configure this correctly?
Specifically:
Do I need to modify pinmux configuration using the pinmux spreadsheet?
Should the pin function be changed from UARTA to GPIO?
Is it possible to configure this at runtime, or does it require reflashing with updated pinmux BCT files?
Is there any additional configuration needed in device tree or pad configuration?
Any guidance or example would be greatly appreciated.
Could you try running the following command instead?
# gpiomon `gpiofind "PR.05"`
Yes, it should be a valid use case as you don’t need the RTS/CTS function for UART1.
If you want to use UART1_CTS (PR.05) on pin 36 of the 40-pin header as a GPIO input, please configure it in pinmux spreadsheet first.
What’s your expected state for this input pin with external button?
Low active or High active?
The re-flashing is required as the pinmux configuration is loaded in early boot stage(MB1).
Regarding the pinmux configuration, I understand that the recommended approach is to modify the pinmux spreadsheet and reflash the board since the configuration is applied during the early boot stage (MB1).
However, since this system is already deployed and reflashing is a bit inconvenient at the moment, I would like to ask if there is any temporary or runtime method to change the pinmux without reflashing. For example, using PADCTL register modification via devmem for debugging purposes.
Would such a runtime workaround be acceptable for testing, or is reflashing strictly required for the pin to function correctly as GPIO?
For the button logic, I plan to use an active-low configuration (default HIGH with pull-up, LOW when the button is pressed).
For additional context, I previously encountered a similar issue with GPIO01 and GPIO11 when configuring them as outputs. Initially, those pins could not be controlled from software and did not respond to output commands. After further investigation, I manually adjusted the corresponding PADCTL registers using devmem, setting the value to 0x00000001. Once this change was applied, both pins began functioning correctly and could be driven HIGH and LOW as expected.
Because of that earlier experience, I attempted the same approach while troubleshooting PR.05 (UART1_CTS) by modifying the PADCTL register using devmem. However, unlike the previous case with GPIO01 and GPIO11, applying a similar configuration did not change the behavior of the pin. The input state still remains LOW when checked using gpioget, even after testing different PADCTL values and verifying that the pin is reported as (MUX UNCLAIMED) and (GPIO UNCLAIMED) in the pinctrl debug output.
Thank you for all the suggestions and explanations.
It turns out the pin is actually working normally as a GPIO input. The issue was caused by the default internal pull-down (~50k) on the pin while the carrier board also has an external 100k pull-up connected to it. Because of this, both resistors were effectively forming a divider and competing with each other, which caused the unstable readings I was seeing.
After disabling the internal pull-down, the pin behaved as expected.