Xavier nx GPIO control

Robotics & Edge Computing Jetson & Embedded Systems Jetson Xavier NX
, ,
1

Hi, I’m using our custom board with xavier nx. And we have to control gpio as well, so I modified pinmux to fit our need.
But there is a strange thing, when I want to control GPIO PQ.06 with libgpiod tools, it didn’t change at all

uihadmin@nvidia:~$ sudo gpioinfo
.....
        line 106:      "PQ.06"       unused  output  active-high
......
uihadmin@nvidia:~$ sudo gpioget 1 106
0
uihadmin@nvidia:~$
uihadmin@nvidia:~$
uihadmin@nvidia:~$ sudo gpioset 1 106=1
uihadmin@nvidia:~$
uihadmin@nvidia:~$
uihadmin@nvidia:~$ sudo gpioget 1 106
0

So I use sysfs to control this gpio

root@nvidia:/home/uihadmin# echo 441 /sys/class/gpio/export
441 /sys/class/gpio/export
root@nvidia:/home/uihadmin#
root@nvidia:/home/uihadmin#
root@nvidia:/home/uihadmin#
root@nvidia:/home/uihadmin# echo 441 > /sys/class/gpio/export
root@nvidia:/home/uihadmin#
root@nvidia:/home/uihadmin#
root@nvidia:/home/uihadmin#
root@nvidia:/home/uihadmin# cat /sys/class/gpio/
export       gpiochip305/ gpiochip335/ gpiochip504/ PQ.06/       unexport
root@nvidia:/home/uihadmin# cat /sys/class/gpio/PQ.06/direction
in

It is very strange that this gpio’s direction becomes IN not our default set OUT . And after using sysfs, gpioinfo can see this gpio becomes in too.
And I change the direction in sysfs, I can control this gpio to output-high or low.

I checked out pinmux setting, it is just right that PQ.06 set as output-low

{
	gpio@2200000 {
		gpio-init-names = "default";
		gpio-init-0 = <&gpio_default>;

		gpio_default: default {
			gpio-input = <
				TEGRA_GPIO(S, 7)
				TEGRA_GPIO(T, 5)
				TEGRA_GPIO(T, 6)
				TEGRA_GPIO(T, 7)
				TEGRA_GPIO(U, 0)
				TEGRA_GPIO(G, 0)
				TEGRA_GPIO(G, 4)
				TEGRA_GPIO(G, 7)
				TEGRA_GPIO(H, 3)
				TEGRA_GPIO(H, 5)
				TEGRA_GPIO(Y, 4)
				TEGRA_GPIO(Y, 5)
				TEGRA_GPIO(Y, 7)
				TEGRA_GPIO(Z, 7)
				TEGRA_GPIO(EE, 0)
				TEGRA_GPIO(EE, 4)
				TEGRA_GPIO(CC, 3)
				TEGRA_GPIO(CC, 4)
				TEGRA_GPIO(P, 5)
				TEGRA_GPIO(Q, 1)
				TEGRA_GPIO(Q, 3)
				TEGRA_GPIO(Q, 5)
				TEGRA_GPIO(L, 2)
				>;
			gpio-output-low = <
				TEGRA_GPIO(S, 4)
				TEGRA_GPIO(G, 2)
				TEGRA_GPIO(X, 0)
				TEGRA_GPIO(AA, 5)
				TEGRA_GPIO(CC, 2)
				TEGRA_GPIO(P, 4)
				TEGRA_GPIO(Q, 6)
				TEGRA_GPIO(B, 0)
				TEGRA_GPIO(N, 1)
				>;
			gpio-output-high = <
				TEGRA_GPIO(CC, 0)
				TEGRA_GPIO(CC, 1)
				TEGRA_GPIO(R, 0)
				>;
		};
	};
};

and in cfg
#### Pinmux for gpio-output-low pins ####
pinmux.0x02213680 = 0x00000003; # CONFIG S4
pinmux.0x0221368c = 0x00000000; # CONTROL S4
pinmux.0x02213690 = 0x00000000; # OUTPUT S4
pinmux.0x02431020 = 0x00000000; # GPIO aud_mclk_ps4
pinmux.0x02214040 = 0x00000003; # CONFIG G2
pinmux.0x0221404c = 0x00000000; # CONTROL G2
pinmux.0x02214050 = 0x00000000; # OUTPUT G2
pinmux.0x02434048 = 0x00000000; # GPIO soc_gpio02_pg2
pinmux.0x02212000 = 0x00000003; # CONFIG X0
pinmux.0x0221200c = 0x00000000; # CONTROL X0
pinmux.0x02212010 = 0x00000000; # OUTPUT X0
pinmux.0x0243d000 = 0x00000000; # GPIO gpu_pwr_req_px0
pinmux.0x0c2f16a0 = 0x00000003; # CONFIG AA5
pinmux.0x0c2f16ac = 0x00000000; # CONTROL AA5
pinmux.0x0c2f16b0 = 0x00000000; # OUTPUT AA5
pinmux.0x0c303028 = 0x00000000; # GPIO can0_en_paa5
pinmux.0x0c2f1240 = 0x00000003; # CONFIG CC2
pinmux.0x0c2f124c = 0x00000000; # CONTROL CC2
pinmux.0x0c2f1250 = 0x00000000; # OUTPUT CC2
pinmux.0x0c302028 = 0x00000000; # GPIO spi2_mosi_pcc2
pinmux.0x02212a80 = 0x00000003; # CONFIG P4
pinmux.0x02212a8c = 0x00000000; # CONTROL P4
pinmux.0x02212a90 = 0x00000000; # OUTPUT P4
pinmux.0x02430070 = 0x00000000; # GPIO soc_gpio04_pp4
pinmux.0x02212cc0 = 0x00000003; # CONFIG Q6
pinmux.0x02212ccc = 0x00000000; # CONTROL Q6
pinmux.0x02212cd0 = 0x00000000; # OUTPUT Q6
pinmux.0x02430030 = 0x00000000; # GPIO soc_gpio42_pq6
pinmux.0x02214e00 = 0x00000003; # CONFIG B0
pinmux.0x02214e0c = 0x00000000; # CONTROL B0
pinmux.0x02214e10 = 0x00000000; # OUTPUT B0
pinmux.0x02446008 = 0x00000000; # GPIO cpu_pwr_req_0_pb0
pinmux.0x02212820 = 0x00000003; # CONFIG N1
pinmux.0x0221282c = 0x00000000; # CONTROL N1
pinmux.0x02212830 = 0x00000000; # OUTPUT N1
pinmux.0x02440020 = 0x00000000; # GPIO soc_gpio54_pn1

Here is this our cfg file
tegra19x-mb1-pinmux-p3668-a01.txt (26.4 KB)

Thanks for help!

3

I don’t understand your logic here.

And after using sysfs, gpioinfo can see this gpio becomes in too.
And I change the direction in sysfs, I can control this gpio to output-high or low.

These two sentences sound contradicting with each other.

Do you have a DevKit for test?
What’s the L4T version?

4

I set this gpio to output-low in pinmux configuration through excel file and generated cfg file to flash the board.
I can see this gpio’s direction is output by libgpiod tools(gpioinfo), but when I use sysfs to see this gpio’s information, its direction is in rather than out.
I manually change the direction by sysfs and set it as output. I can change value as well.
And after using sysfs I unexport this gpio, using gpioinfo again to get the gpio information. this gpio’s direction becomes input

No, because other gpio works fine and L4T version is R35.5.0

5

Please still find a DevKit for validation.
The board wiring maybe problematic.

6

But I don’t think tihis is related to board design.
gpio set is just come from the module and our question is why the direction of gpio is not as same as pinmux setting.
If the direction is correct, the fuction works fine. So it seems not related to board wiring thing.

7

Please make sure the same thing also happens on DevKit so we can replicate and debug.
Or you flash the device wrongly so the customized pinmux does not even take effect.

8

okay, but I don’t have a devkit to test. And I reflash the board I can confirm other gpio’s customized pinmux does take effect

9

So only PQ.06 is behaving incorrectly?
I will check locally with a DevKit.

10

From our usage, yes. Our customized gpio pin works fine except PQ.06

11

I just noted that your command usage is incorrect.
You need to add --mode=wait so the voltage change persists untill you press ENTER, or the ffect will be gone as soon as the process returns.

Make sure it works this way before we check the direction issue, though I think it’s no big deal.

12

I found the reason
It is no problem at all. I think gpioget is just getting the value, but it will change gpio’s direction to input, so I just need to set it and it works fine.
Our other custom gpio tested by measuring voltage rather than use gpioget to see if its value is correct.
Thanks for help

1 Like
13

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