Can't seem to control GPIO pin output voltage (high/low) on Jetson Xavier NX developer KIT (40-pin)


I’m trying to control a GPIO pin – set to high and then set to low.
I’m using Jetson Xavier NX developer KIT, measuring the ouput of the pin on a 40-pin Expansion Header using a fluke, connected one probe to a ground pin and the other to the pin which I want to see the output change on.
I tried changing the pin value using:

  1. gpioset command
  2. C++ - ioctl
    Both methods give the same behavior, but the behavior is not what I expect.
    For example, even if the vlotage goes up from 0.0 to more than 1 when I run gpioset with 1, it doesn’t go back down when I run the gpioset command with 0.

I tried with a few pins (it doesn’t matter to me which one as long as it works as expected).
Those are the ones I tried to change and measure:
PIN 11
PIN 29

Is there a way I can make it work?

Thank you!


hello b_tata1,

could you please check release tag to confirm the release version you’re working with.
for example, cat /etc/nv_tegra_release

Hello JerryChang, here it is:

R35 (release), REVISION: 1.0, GCID: 31346300, BOARD: t186ref, EABI: aarch64, DATE: Thu Aug 25 18:41:45 UTC 2022

hello b_tata1,

there’s GPIO allocation range changes since kernel-5.10,
you may check you’re toggle the correct pin number to alter the pin,

please double check the GPIO number via debugfs.
let’s taking GPIO09 / GPIO3_PS.04 as an example,
# cat /sys/kernel/debug/gpio | grep PS.04
gpio-453 (PS.04

1 Like

Hello Jerry,
I am working together with Tanya on the problem and she is currently unavailable so I will continue this thread.
I have performed what you have written and I am getting:
nvidia@JetsonNX:~$ sudo cat /sys/kernel/debug/gpio | grep PS.04
gpio-453 (PS.04

Is that OK? What next?
I am not sure we understand the mapping between the pins on the 40pin J12 and the gpioset command.

We are looking at Jetson_Xavier_NX_DevKit_Carrier_Board_Specification_v1.0.pdf.
We have found out Table 3-3.
In that table, we have found out for example that:

  • Header Pin# 15 , is called GPIO12 as “Module Pin Name” , 218 as “Module Pin #” and PCC.04 as SOCE GPIO Port#
    We were looking at this exact pin because it was the only pin that looks free (as it doesn’t even have any “Alternate Functionality”)

We have done:
nvidia@JetsonNX:~$ sudo gpioinfo | grep PCC.04
line 16: “PCC.04” unused input active-high

And then
nvidia@JetsonNX:~$ sudo gpiochip 2 line 16
(it is gpiochip 2 in the chip list and line 16 in that speciifc chip).

So with all that information what are we doing wrong?

1 Like

hello eran.peled,

gpio-453 is the gpio number used by linux kernel.
please try you could toggle the pin via sysfs. please grant root permission to try this,
for example,
$ sudo -i
# cd /sys/class/gpio
# echo 453 > export
you shall see the gpio node has created, then you’ll be able to enter the location of the GPIOs for controlling.
# cd PS.04
# echo out > direction && echo 1 > value

please check all the pins as above you cannot control via gpioset commands or, C++ IOCTL.
looking forward your test results.

Hi Jerry,
Thanks for the quick replay.

I have tried the sequence you had written above , while connecting to J12 pin 7 (which is GPIO09) to a positive fluke probe and J12 pin 6 (which is Ground) to a negative fluke probe.
At first, I have had some inconsistency with my results. Let me explain.
• Before doing anything fluke reading = 0Volts
• “echo out > direction && echo 1 > value” resulted with 1.6Volts
• “echo out > direction && echo 0 > value” resulted with 1.6Volts
• “echo out > direction && echo 1 > value” resulted with 1.6Volts and then out of nowhere jumped to 3.3Volts
• “echo out > direction && echo 0 > value” + removing and reconnecting the positive probe resulted with 0Volts , but sometime 1.6Volts
• “echo out > direction && echo 1 > value” resulted with 1.6Volts or 3.3Volts

Then I have commanded:
• “echo in > direction”
• “echo out > direction && echo 1 > value” resulted with 3.3Volts
• “echo out > direction && echo 0 > value” resulted with 0Volts
Which seems as consistent behavior.

  1. Is the inconsistent behavior I have got before is a known hardware issue?
  2. Is the consistent behavior after performing the “in” configuration could be a solid workaround?
  3. Could you refer me to the most c/cpp user-space code example, which controls gpios output with the lowest latency possible?

Thanks a lot,

update - 2023-03-09:
The workaround (2 - above) does not always work. I have returned to my hardware after a day and I cannot reproduce this workaround “magic”.

1 Like

Hi, for the output pin voltage level issue, please refer to Jetson Nano Developer Kit 40-Pin Expansion Header GPIO Usage Considerations Applications Note in DLC first. There are some requests to the load of pin as a level shift exists.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.