Hi,
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:
- gpioset command
- 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 15 GPIO12
PIN 7 GPIO09
PIN 11
PIN 29
Is there a way I can make it work?
Thank you!
Tanya.
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
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?
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.
- Is the inconsistent behavior I have got before is a known hardware issue?
- Is the consistent behavior after performing the “in” configuration could be a solid workaround?
- 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,
Eran.
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”.
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.