Hi everyone,
Since transitioning from the Jetson Nano and Orin Nano to the Orin NX, we’ve encountered an issue that we haven’t been able to resolve. We’re using the GPIO with the Python Jetson.GPIO library to define some pins as input and others as output.
Specifically, we’re using pins 17, 27, 22, and 23 as inputs, and they work perfectly. However, pin 18, which we use as an output, no longer functions correctly on the Jetson Orin NX.
I’ve reviewed several topics and posts but haven’t been able to pinpoint the problem.
Here’s a snippet of the Python code we use to reproduce the issue:
import Jetson.GPIO as GPIO
import time
output_pin = 18 # BCM-Nummerierung
GPIO.setmode(GPIO.BCM)
GPIO.setup(output_pin, GPIO.OUT)
try:
while True:
GPIO.output(output_pin, GPIO.HIGH)
time.sleep(2)
GPIO.output(output_pin, GPIO.LOW)
time.sleep(2)
finally:
GPIO.cleanup()
Does anyone have any ideas or suggestions on what might be going wrong?
Thanks in advance!
Hi markus.rohr,
Are you using the devkit or custom board for Orin NX?
What’s your Jetpack version in use?
Jetson Nano and Orin Nano/NX come with different Jetpack release and also different pin mapping.
Are you trying to use PIN18 of 40-pins expansion header on Orin NX+p3768 devkit board?
Hi KevinFFF
We use the reComputer J401 Carrier Board.
Jetpack 6 (nvidia-l4t-core 36.3.0-20240506102626)
It would surprise me if the pin mapping has changed. The inputs are still functioning as usual. However, I can’t control the pin that has been defined as an output. We use the reComputer J401 Carrier Board.
Let me share the PIN18 of 40-pins header between Jetson Nano devkit board(p3449) and Orin Nano devkit board(p3768).
P3449
PIN18 → SPI1_CS0 → PB.07
P3768
PIN18 → SPI1_CS0 → PZ.06
As a result, you should configure PZ.06 on Orin Nano/NX instead of PB.07.
I’m not clear about your custom carrier board design. You should check this with your vendor.
In Jetpack 6, you have also need to configure the pinmux for this pin as Output or Bidirectional before use.
Could you also share the result of the following command on your board?
$ sudo busybox devmem 0x0243d008
The result for the command with busybox is: 0x00000059
I’m not sure if we are talking about the same thing. To my understanding, a 40-pin header always has the same numbering, starting at 1 and ending at 40. It might be that the carrier board has different routing to the pins, but that shouldn’t have any impact since the pin number of the 40-pin header is specified using Nvidia’s official library (GitHub - NVIDIA/jetson-gpio: A Python library that enables the use of Jetson's GPIOs) and not the one for the Jetson Nano or Orin NX, etc. Furthermore, I would see the high signal on a different pin in that case, but this is also not happening. No pin is being set to high. The mode is also defined through this library, isn’t it? Could you show me the reference where it says the mode needs to be set differently? Thank you very much.
Yes, it seems your pinmux register for PIN18 of 40-pins expansion header is configured as input by default.
Please configure it as Output before use no matter you are using Jetson.GPIO or gpiod.
You can use gpioinfo to check its state and use gpioset to control it output high/low.
Thank you for the hint about gpioinfo and gpioset.
I now clearly see which pin is being used by Jetson-GPIO. Pin number 18 corresponds to line 50 of the gpiochip0chipset.
As soon as I start the regular script to use Jetson-GPIO, it assigns line 50, also known as PH.07, to Jetson-GPIO, defining it as an output with an active-high value. However, the script does not change it to active-low. In fact, the pin should be active-low, not active-high.
After I stopped the script, the pin was declared as unused.
Then I used the command sudo gpioset gpiochip0 50=0, but there was no change; it remained active-high. It should have been low after this command, right?
Interestingly, pin line 126 (PY.04) works correctly as an input. However, when I tried to use it as an output, I encountered the same issue—I was not able to control it, whether with Jetson-GPIO or with gpioset.
May I ask, Kevin, do you have an Orin NX in front of you and have you successfully controlled this pin? Have you successfully measured the change from low to high and vice versa with a measuring device?
Could you try adding --mode=wait in this command as following?
# gpioset --mode=wait `gpiofind "PH.07"`=0
Yes, I’ve verified that the above command could work to control PIN18.
Please make sure that you’ve used pinmux spreadsheet to configure this pin as Output/Bi-directional before use.
Hi Kevin. This results in:
line 50: "PH.07" "gpioset" output active-high [used]
Pin still not active high, nothing happens.
That’s really crazy. I tried it with 5 different devices. All of them have the same behaviour.