GPIO not toggling

I’m trying to blink some LEDs attached to some GPIOs on my jetson nano module. It’s plugged into a custom carrier board, and the path from the pins to the LEDs has been verified.

The pins in question are SPI2_MOSI and SPI2_CS0. When I boot it up, gpioinfo shows the following:


But if I try to twiddle those pins, this happens:

$ gpioget 0 12 15
0 0
$ gpioset 0 12=1 15=1
$ gpioget 0 12 15
0 0

Has anyone ever seen this before? What could cause it? I spent a lot of time trying to verify my pinmux, and that the device tree in use is the one I built, but gpioinfo seems to say that I’ve got it configured correctly.

  1. Which jetpack release in use?

  2. Are only those pins not working or every of the GPIO on your board cannot work?

  1. I’m using l4t version 32.7.2 from L4T Archive | NVIDIA Developer

  2. I haven’t tried all the other pins, but I am using several for buttons that work fine and one pin (pwm2) as PWM.

I have tried on different boards, so it’s not the nano module.

Sorry for the late response, have you managed to get issue resolved or still need the support? Thanks

hello user103826,

would you please alter the pin via sysnode instead of using libgpiod.
the GPIO number of GPIO3_PB.04 is 12, you may generate gpio12 under location of the GPIOs /sys/class/gpio/ for controlling.
for example,
# echo 12 > /sys/class/gpio/export
# cd /sys/class/gpio/gpio12
# cat value

@kayccc @JerryChang
The accepted solution has not solved the issue. We have been deep in the weeds digging through documentation and trying to rebuild UBoot so that the device tree is loaded correctly by the Nano.

It seems that there is an issue with the UBoot build issued for the EMMC based Nano module, where the device tree is not loaded correctly.

We are seeing the following issues:

  • GPIO pins cannot be set to outputs, the can only be configured as inputs
  • PWM driver does not always initialize correctly - sometimes it does, sometimes it doesn’t, and a reboot is needed to get it to initialize.

These issues are not resolved by appropriate settings in the device tree.

We did not have these problems when using the Nano devkit, only when switching to the EMMC based module.

Have you seen this type of issue reported by other Nano module users and would it be possible to verify on your end that the device tree settings can indeed be loaded correctly with the Nano module SDK?

@WayneWWW the version is 32.7.2 version of the BSP for the Jetson Nano

hello user79370,

may I know what’s the actual use-case, please note that the DTB is loaded and used by CBoot on Nano, not U-Boot.
you should try interrupt uboot and set the pinmux and gpio register via ‘write 0xXX’ commands to program the pin.
in addition, please try toggle the pin in uboot sources, such as… int dm_gpio_set_dir(struct gpio_desc *desc);
please see also, uboot_src/include/asm-generic/gpio.h

Thank you for your response!

The actual use case is driving LEDs with a GPIO output. We are driving two LEDs with a simple On/OFF drive, and two with a PWM drive.

Can you point us to documentation on the uboot interrupt command (is it esc for your build? or another key command) - are there any other configurations we need to do to get the uboot to enter into a serial terminal? We currently do not see uboot text as part of the boot process.

Also do you have documentation on the write 0xXX commands? We aren’t familiar with those. Is the idea you are suggesting to see if the pin write works in uboot but not once the kernel is booted? Can you provide more detail on the troubleshooting intention?

Regarding toggling the pin in uboot sources, is that also a different troubleshooting step that will tell us different information that using the command line?

Obviously our goal is to get this working in our application when the full OS is running, so I want to be clear on the troubleshooting steps you are proposing and the next steps we would take depending on the output of these tests.

Have you been able to reproduce this issue on your side? Is this something you’d be able to test? The test would be booting and EMC based Nano module and then attempting to use and GPIO pin as an output to set high and low.

Sorry for the self shilling but I created a library that should work for your use case if you are willing to create your app in C or C++, it works independently of kernel configuration.
It is still a BETA and that’s why I am interested in getting people’s feedback to be able to improve it, this is my github in case you want to have a go: GitHub - Rubberazer/JETGPIO: C library to manage the Jetson Nano GPIO
Public domain, so no license issues.

it’s suspect the incorrect pin configuration, due to Nano series using device tree for pinmux settings, please disassembler the dtb file into text file to examine the configuration. i.e. dtc -I dtb -O dts -o output.txt tegra210.dtb

Hi @JerryChang Thank you for your response. I’ve attached the device tree output for your review. We have seen that the device tree doesn’t appear to be respected on kernel boot, as the GPIOs do not respect the input/output designation. However, if you can see something incorrect with the device tree setup, please let us know! See the original post for the pins in question.
output.txt (318.7 KB)

Hi @Rubberazer Thanks! We’ll take a look, and let you know if it works for us :)

hello user79370,

it’s Cboot for doing full pinmux and GPIO init. that’s checking the DTB files.
please review your dtsi settings, do you have configuration as below?

			spi2_mosi_pb4 {
				nvidia,pins = "spi2_mosi_pb4";
				nvidia,function = "rsvd2";
				nvidia,pull = <TEGRA_PIN_PULL_DOWN>;
				nvidia,tristate = <TEGRA_PIN_DISABLE>;
				nvidia,enable-input = <TEGRA_PIN_DISABLE>;
			spi2_cs0_pb7 {
				nvidia,pins = "spi2_cs0_pb7";
				nvidia,function = "rsvd2";
				nvidia,pull = <TEGRA_PIN_PULL_DOWN>;
				nvidia,tristate = <TEGRA_PIN_DISABLE>;
				nvidia,enable-input = <TEGRA_PIN_DISABLE>;

you may also check… $ sudo cat /sys/kernel/debug/tegra_pinctrl_reg | grep spi1 for the address value.
it’s bit-4 and bit-6 to report pin direction. whereas, Output: Bit 4 = 0 Bit 6=0, Input: Bit 4=1 Bit 6=1.

Hi @JerryChang :

Yes, the device tree shows those settings. And this is the output of the command you suggest:
Bank: 1 Reg: 0x70003064 Val: 0x00006016 → spi2_mosi_pb4
Bank: 1 Reg: 0x70003068 Val: 0x00006016 → spi2_miso_pb5
Bank: 1 Reg: 0x7000306c Val: 0x00006016 → spi2_sck_pb6
Bank: 1 Reg: 0x70003070 Val: 0x00006016 → spi2_cs0_pb7
Bank: 1 Reg: 0x70003074 Val: 0x00006015 → spi2_cs1_pdd0

This is the issue we are having - the device tree appears to be correct, however, upon loading it, the settings are not respected.

Perhaps this is an issue with CBoot related to the EMC module?
Is there any other check you can suggest where we might be able to see where the issue is occurring?
Have you been able to confirm on your end that the EMC based Nano module loads GPIO device tree settings correctly?

As noted earlier, the other issue we are seeing is that the PWM driver does not load correctly sometimes. It fails to load about 1/8 times. This we think may be related to the device tree not properly loading, since we are seeing the issue with the GPIO pins. Where can we look to resolve this PWM driver load issue?

hello user79370,

just for confirmation, did you meant eMMC modules, which has the 16GB storage?

@JerryChang yes, that is correct

To make the pinmux configuration really takes effect, doing full flash with your to flash your dtb.

HI @WayneWWW thank you for your response. We’ve had some issues with the script. When we have used it, the board doesn’t boot at all. Have you seen this issue before?

To get around this, in order to flash the dtb, we’ve been writing it into the expected memory location and ensuring the bootloader is pointed to the right location. Is there a reason why this would not work?


You better dumping the uart log so that we can tell whether it is really not able to boot, or just something else.
For example, sometimes monitor is dead but system still boots up.

Also, tell us how you flash boards with In most cases, new users don’t know how to use script correctly…

1 Like