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
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?
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.
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.