I am using a Jetson Nano 4GB, but I have the same issue with the Jetson Orin.
I am trying to drive my GPIOs high and low, but driving them is a bit unpredictable. I get some transient state of about 1.8V before it might end up at the right state.
What I have right now is a pull-up resistor of 10MOhms to 5V (and I’ve also tried as low as 1kOhms) to keep my NMOS on by default, but even with that pull-up, the GPIO is unstable.
AI tells me the issue comes from a parameter called “E_IO_HV”, but I don’t know for sure if that’s the source of the problem or how to verify if it’s enabled or not.
Please make sure the pin is configured as GPIO rather than SFIO, with E_IO_HV disabled and tristate not enabled, then regenerate the pinmux and reflash the board, since our documentation states that E_IO_HV must be disabled when a pin is used as GPIO.
If you still see the pin sitting around 1.8 V for 1–2 seconds, that is not expected normal GPIO behavior and is more likely related to the pinmux/pad configuration or an external level shifter/circuit path issue.
I did configure it as GPIO through the dts, tristate is 0.
When I devmem2 on my pin’s register after reboot (0x70003050 for pin 19 of the carrier board), I get 0xE005 (I understand Smitt trigger enabled, drive type 0b11, pull down and SFIO).
I try setting it up as output and output high and low. High gives me the expected 3.3V, but low stays as 1.8V.
So then I set the register value to 0x8004 (drive type 0, GPIO, pull down).
High and low seem now normal, with 3.3V on high and 0V on low.
Same for 0xC004 (drive type 0b10).
But 0b01 and 0b11 give me those strange voltages.
I have set my DTS with hog on the gpio16 (for pin 19), put it in the common node of pinmux@700008d4, tristate 0, pull to 1, enable-input to 0, function to rsvd0. But still when I reboot, the register is back to 0xE005.
What properties can I use to force set the drive bits please?
Thanks, this points to the bootloader pinmux, not GPIO hog. On Jetson Nano, pinmux is applied by CBoot from the spreadsheet-generated pinmux files and is not reapplied by the kernel, so if the register returns to 0xE005 after reboot, the flashed pinmux configuration is still not the one you changed.
For a persistent fix, please modify the correct generated pinmux dtsi for your Nano board, rebuild the DTB, and reflash. Also check cat /proc/device-tree/nvidia,dtsfilename to confirm you are editing the matching board file, not only the gpio dtsi.
OK, so in theory it shouldn’t matter if I generate the DTS from the pinmux spreadsheet or if I edit the dts by hand (given that I do use the right properties and nodes), is that correct?
Or is the nvidia,dtsfilename also applied and would its properties persist after CBoot if they weren’t changed in the DTB?
In order to have the changes reflect at boot time, you need to flash the updated pinmux dts files. Refer abv link to modify pinmux sheet and flash them…
Thank you, the reason I’m reluctant to use the spreadsheet is because I’ve gone through the DTS a lot, and also I’m on Ubuntu and I prefer to check other possibilities before trying to switch to Windows.
On the Jetson Nano, I set the register 0x70003050 (gpio16, so pin 19 of the carrier board), strangely, it’s still 0xE005 (SFIO and pull-down) instead of 0xE004 (pull down, rsvd0/GPIO), even though I set it the same as on the OKdo and in this case it worked.
And before, I had a pull-up resistor to 3.3V on my GPIO, and setting the register to 0x8004 would pretty much make it stable and output what I want (0V when setting it low, 3.3V when setting it high - and almost instantly, which is not what would happen with 0xE005).
I understand the spreadsheet is probably more accurate in setting the correct nodes in the DTS, but I’m really starting to wonder whether there are additional ICs on the carrier board that have some enable pin required to correctly function as GPIOs.
Any idea what could be the problem? Do you find it strange that a GPIO configuration (in pinmux@700008d4 and hogged in gpio@6000d000) working on OKdo wouldn’t work on Jetson Nano?
Did not understand what do you mean by OK here?? Is it Orin Kit…
One thing is, there is something called padctl stuff apart from changing gpio from input/output high/low to make things work. you may need to change them using devmem command accordingly for changing them as input/output.That’s the reason PINMUX spreadsheet method is best to configure the pins perfectly.
Also pls download Technical Reference Manual TRM pdf for Jetson Nano from nvidia website download archive, for more details about this pin mux register, pad ctl values etc…
I meant the OKdo C100 board, a replication of the Jetson Nano.
I thought maybe it was pinctrl, but for some reason, Claude AI says it’s not necessary to add any phandle or pinctrl-… to make the gpio active in gpio@6000d000.
But for padctl, isn’t that only for USB? I don’t think that’s what I’m missing.
Plus, it shouldn’t be about pinctrl in pinmux@700008d4, since it works for the OKdo board.
I set pinctrl-0 to <0x3d> (which is the phandle of the “common” node, in which I have put my pin configurations)
Yes, hand-editing should also work, but only if you modify the correct bootloader pinmux file and then rebuild/reflash it, since on Jetson Nano the pinmux is applied by CBoot, not persistently by the kernel.
nvidia,dtsfilename is only for identifying which DTS/board file is in use; it is not itself a pin setting.
Do you mean that modifying the dts, compiling it into dtb (with the right file name referenced under extlinux/extlinux.conf with FDT) and rebooting is not sufficient?
I’m not sure how to reflash since I’m booting on microSD.
Thanks,
Tom