Jetson Nano GPIO related question


For Jetson Nano develop kit, I used R32.3.1 for Jetson Nano, and saw device tree file is tegra210-p3448-0002-p3449-0000-b00.dts

I used standard BSP: JetPack_4.3_Linux_JETSON_NANO downloaded from SDK manager, tried to test GPIO for pin 33 on Expansion Header.

I used function as:

echo 38 > /sys/class/gpio/export

echo in > /sys/class/gpio/gpio38/direction

cat /sys/class/gpio/gpio38/value

echo 38 > /sys/class/gpio/unexport

I monitored the value on terminal when typing “cat /sys/class/gpio/gpio38/value”.

I expected that the value should be changed from 0 -> 1, if I short pin 33 and pin 34, but it’s not.

The returned value for “cat /sys/class/gpio/gpio38/value” just keeps “0”.

Please feel free to let me know if I got misunderstanding. Thanks a lot.

hello VergilTien,

had you configure the pin direction for your use-case?
please also refer to Configuring the 40-Pin Expansion Header to enable Jetson‑IO for pin configuration.

Hi Jerry,

I’m sorry to reply late.

For the command “echo in > /sys/class/gpio/gpio38/direction”, it should configure the direction for the gpio, if there is no misunderstanding.

I didn’t additionally use the section “Configuration the 40-Pin Expansion Header”, because I considered that I used the standard BSP downloaded from SDK manger without re-building dtb file, and checked the pinmux table for Jetson Nano , the table defines pin 33 as general GPIO function, and direction “in”.

That’s why I directly used above commands, and expected I can get different responded value when shorting pin 33 and 34 on 40-Pin Expansion Header.

Thanks a lot.

hello VergilTien,

there’s pad have internal pull up/pull down configurable in pinmux register, you may access TRM, check Chapter-9.15 for more details.
suggest you may check similar discussion thread, Topic 40750 and also GPIO Interfacing for reference.

Hi Jerry,

Thanks for your info.

Updated status:
I temporarily gave up testing pin 33 on Expansion Header, because I don’t know if it’s PWM signal, then caused my above mentioned.

I further experimented pin 15(LCD_TE) on Expansion Header.

I used “NV_Jetson_Nano_Module_Pinmux_Config_Template.xlsm”, Revision is 1.01, and config Ball name “LCD_TE”, the related part on "tegra210-porg-pinmux-p3448-0002-b00.dtsi"is as:
lcd_te_py2 {
nvidia,pins = “lcd_te_py2”;
nvidia,function = “rsvd1”;
nvidia,pull = <TEGRA_PIN_PULL_UP>;
nvidia,tristate = <TEGRA_PIN_DISABLE>;
nvidia,enable-input = <TEGRA_PIN_ENABLE>;
and “tegra210-porg-gpio-p3448-0002-b00.dtsi” also defined "TEGRA_GPIO(Y, 2) " in property “gpio-input”.

After that, I re-built dtb by steps mentioned from “Updating the Bootloader Pinmux” in section " Jetson Nano Platform Adaptation and Bring-Up"

Finally, I re-flashed my Nano dev kit by $sudo ./flash -r jetson-nano-emmc mmcblk0p1

When OS is ready, I checked the responded value for commands:
echo 194 > /sys/class/gpio/export
echo in > /sys/class/gpio/gpio194/direction
cat /sys/class/gpio/gpio194/value

Because I might set the pin to pull-up and direction “in” in default, the responded value should be “1”, but it’s kept “0”. I am stuck for the problem.

There should be very simple test, please let me know if there is any misunderstanding. Thanks a lot.

hello VergilTien,

you don’t need to export GPIO pin manually if you’d already specify the usage via pinmux configuration.
suggest you should probe the pin to check the voltage changes.

Hi Jerry,

Thanks for your comment.

Based on device tree configuration as above mentioned(Set GPIO pin through pinmux table and flash to Nano DVK board), I found the voltage for pin 15(LCD_TE) is 0 V when probing between pin15 and pin GND.

According to pdf “Jetson_Nano_Carrier_Board_Concept_Schematics”, there should be 3.3V for pin 15.

I’m sure my multimeter for voltage works properly, because the voltage value is good if I probed pin 5V or 3V3.

Please feel free to let me know if I miss configuring any part.

Thanks a lot.

Hi Jerry,

Thanks for your help in the issue.

I’d selected the solution.