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.
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.
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?
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
thanks
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)
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.
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?
HI @WayneWWW thank you for your response. We’ve had some issues with the flash.sh 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 flash.sh. In most cases, new users don’t know how to use script correctly…
