I am trying to modify my device tree (dt) to create an overlay that would allow me to use pin 7 and pin18 of the expansion header as a GPIO output and use “gpioset 0 144=1” and “gpioset 0 125=1” to set the output from these pins. I am using the attached .dts file (modified to a .txt file so I could send it) to create the dt overlay by for pin7 and pin18 and to my surprise, all works wrt pin7 , but wrt pin 18, I can set the output with “gpioset 0 144=1’ but it doesn’t go to 3.3V, but only to 1.56V and once I set it, I can’t clear it using the command “gpioset 0 125=0”. However no issues with setting and clearing pin 7. Do you know what is wrong with this dt overlay file wrt pin 18 that I am doing wrong?
I am using the devkit for Orin Nano and using Jetpack v6.2. What’s weird is that it works for pin7, no problem - I can clear and set the pin using gpioset and it goes from 0 to 3.3V each time. However for pin15, it goes to 1.56V when set and once set, it won’t go back to 0V, just stays at 1.56V.
It’s been a while since I have applied a patch. To be clear, I need to save the text to a file like “my_file.patch” and apply
patch -p1 < my_file.patch
If so, what directory do I need to be in on my Orin Nano when doing this? Please advise.
From looking through the file referenced in the link, it appears that I execute in the patch on my laptop that has the Jetpack manager installed, correct? And if so, what directory? And once I do this, how do I get results applied to my Orin Nano? I’m a bit new to the NVidia way of doing things so need a bit more coaching on how to do this.
Ok, thanks for making that more clear, but still a bit confused. I will need to apply this patch to the file pinctrl-tegra234.c in a drivers/pinctrl/tegra directory. I see no such file or directory from installing JetPack v6.2.1 on my Ubuntu 22.04 laptop. So is this patch for an older version of JetPack or am I missing something here?
Once I know where this file is located so I can apply the patch, then to be clear, I will need to rebuild the kernel and replace the uImage file on my Orin Nano with the one generated from the rebuild of the kernel, correct?
Yes, you are correct - I mistyped. I figured out how to pull in the latest kernel and make the necessary patch to the right file and build the kernel. However after doing so and running with this newly built kernel with the patch applied, nothing changed - still the same problem. So I tried a few other pins on the expansion connector: pins 29, 31 and 33 and all had the same problem. So for some reason, pin 7 works with gpioset 0 144=1 and gpioset 0 144=0 going to 3.3V and 0V, respectively. But pins 16, 18, 29, 31 and 33 go to 1.5 V using gpioset 0 X=1 and then doesn’t change from 1.5V when using gpioset 0 X=0. This was measured using a Fluke voltmeter probe on the respective pin during each test.
From further testing, I found out that if I removed the voltmeter probe from the respective pin and then re-inserted the voltmeter probe, then the problem goes away. Hence to fix this problem after using gpioset, just remove the probe and re-insert the probe and then it measures the proper voltage. So obviously a loading issue here, but the Fluke probe is high-impedance so this is certainly not from applying too much of a load during the testing. It apparently needs some minor tweaks to the loading to get it to work. So I put a 3.3K Ohm resistor in-line with the probe to the respective pin and the problem goes away - gpioset 0 X=1 going to 3.3V and gpioset 0 X=0 going to 0V for each and every pin.
At least I got a solution that works now, but don’t fully understand what needs to be done to resolve this issue without playing around with resistance values to get it to work. Your thoughts as to what is the probem here and what is the proper fix?
Do you configure the pinmux for those pins through pinmux spreadsheet before use?
i.e. I would expect that you’ve configured them as GPIO/Output/Drive 0 or 1 if you want to control them manually.
Please also add --mode=wait for gpioset command to keep its state.
e.g. PIN16 of 40pins header(J12)
If I type what you referenced for pin18, I get the following:
user@ubuntu:~$ gpioset --mode=wait ‘gpiofind “PY.03”’=1
gpioset: at least one GPIO line offset to value mapping must be specified
Instead if I type the following for pin18:
user@ubuntu:~$ gpiofind PY.03
gpiochip0 125
and then type the following:
user@ubuntu:~$ gpioset --mode=wait 0 125=1
the output goes to 1.5V and the command never returns. I have to type c to terminate. However if I remove the probe from the voltmeter and reapply it, the voltage reads 3.3V. And if I add the 3.3K Ohm series resistor in line with the voltmeter, then typing the following:
gpioset --mode=wait 0 125=1 => output goes to 3.3V
c
gpioset --mode=wait 0 125=0 => output goes to 0V
c
The “–mode=wait” does not make any difference in the result other than requiring me to have to enter c each time I use it so I just avoid this by only issuing gpioset without the “–mode=wait”.
Yes I use the pinmux by using the attached files (device tree overlay files) depending on if I am testing for either pin 7, pin 18, pin 31 or others as well. All works ok (output goes to 0V and 3.3V correctly), if I put a 3.3K Ohm series resistor in-line with the voltmeter. But if I just have the voltmeter probe on the respective pin when I issue gpioset 0 X=1, the output goes to 1.5V and never changes even when issuing gpioset 0 X=0 or any further gpioset commands. However if I remove the voltmeter probe and reapply it, the output behaves appropriately. So this does not appear to be softare or configuration problem, but some hardware loading issue with the respective pins on the 40-pin expansion header. For some reason though, this problem does not occur for pin 7. Only pins 16, 18, 29, 31 and 33 that I have tested do. Let me know if you find otherwise and/or have a better solution than having to add series resistance to get the output to behave properly.
BTW, for some reason this forum editing tool removes the typing of control-c with control between < and > like < CTRL >. So when you see just c in my response above I mean < CTRL > c to exit the command with the mode option.
Please enter sudo permission first. (i.e. run sudo su before run gpioset)
It is ` rather than ‘ and ’ for gpiofind command.
It is expected that command won’t return as the --mode=wait is specified to keep its state before the process ends.
I would suggest using scope to check its state as it 1.5V may be caused from that the known SFIO bit been set issue.
About this behavior, I’ve checked with hardware team.
The signals on the expansion connector go through a TI level shifter rather than connect directly to Orin. Looking at that level shifter’s datasheet, there is a section that says a very heavy capacitive load can prevent the signal from being fully driven to the output voltage. The level shifter is designed for capacitive loads up to 70pF, so perhaps the probe plus the voltmeter are exceeding this 70pF capacitance.