PINMUX, GPIO Change Overlay

Robotics & Edge Computing Jetson Systems Jetson AGX Orin
,
1

Hi Community,

Anyone was able to change the pinmux gpio without reflashing/replacing the entire Image?

$ grep -r “soc_gpio23_pp4” /boot
grep: /boot/Image: binary file matches

I’m not sure I understood the steps on Documentation. I need to reflash my board again to change if a gpio is on pull_up to pull_down? Or just recompiling the Image and replacing it will suffice?

Example:

            soc_gpio23_pp4 {
                nvidia,pins = "soc_gpio23_pp4";
                    nvidia,function = "vi0";

                    + nvidia,pull = <TEGRA_PIN_PULL_UP>;
                    - nvidia,pull = <TEGRA_PIN_PULL_DOWN>;

                    nvidia,tristate = <TEGRA_PIN_ENABLE>;
                    nvidia,enable-input = <TEGRA_PIN_ENABLE>;
                    nvidia,io-high-voltage = <TEGRA_PIN_DISABLE>;
                    nvidia,lpdr = <TEGRA_PIN_DISABLE>;
            };

Can I create an overlay (it should be more or less like that I think):

/dts-v1/;
/plugin/;

/ {
fragment@0 {
    target-path = "/pinmux@2430000";
        __overlay__ {
        soc_gpio23_pp4 {
            nvidia,pins = "soc_gpio23_pp4";
            nvidia,function = "vi0";
            nvidia,pull = <2>;
            nvidia,tristate = <1>;
            nvidia,enable-input = <1>;
            nvidia,io-high-voltage = <0>;
            nvidia,lpdr = <0>;
            };
        };
    };
};

Compile it to dtbo and add that to the /boot/extlinux/extlinux.conf

Or are there an easier way to change that? I saw that we can use busybox but that isn’t reboot persistant, and I don’t want to look for each register while deving.

Thanks

4

Hi @tarcisio.jaolive,

I hope you are doing well.

  • For pinmux changes , you need to reflash the board with the new .dtsi files generated from the spreadsheet and update your machine configuration (board.conf) accordingly, as mentioned in the NVIDIA documentation.

  • Overlay suggestion: Not sure about this approach but if the pin you want to modify is not critical to the bootloader, using a DTB overlay might work to apply changes at runtime and make them persistent after boot. However, changing a boot-critical pin via overlay could also cause boot failures. Might be worth it to give it a try.

  • For keeping the changes done after boot, I suggest creating a systemd service that runs at boot and executes your busybox devmem commands to configure the pinmux at runtime. This allows you to avoid reflashing during development. You could follow this guide for changing the pinmux using busybox: Changing the pinmux

Let me know if this helps.

Best regards,
Nico
Embedded Software Engineer at ProventusNova

6

Hi tarcisio.jaolive,

Are you using the devkit or custom board for AGX Orin?
What’s the Jepack veriosn in use?

Yes, you would need to reflash the board.
Instead of reflashing the whole board, you can simply run the following command to flash QSPI only, which may prevent you erase the APP partition.(i.e. rootfs)

$ sudo ./flash.sh -c bootloader/generic/cfg/flash_t234_qspi.xml jetson-agx-orin-devkit internal

This method is just like what jetson-io tool would do.
There’s a pinctrl driver in kernel can also configure the pinmux according to what you add in device tree, but I would still suggest using pinmux spreadsheet as the generated pinmux/gpio dtsi will be loaded in early boot stage(i.e. MB1) rather than kernel.

7

DevKit AGX,
I did use busybox yesterday to change input to output and it worked, but I don’t know if the pull mode would change if i changed there and not since reboot so I did not wanted to do it until I got an answer here. I did end up changing with the complete flash yesterday. Will test the pseudo-flashing with just the QSPI if i need to do further changes.
@nico.morua What would define a boot-critical pin or not? The GPIO I want to use is set as unused so I imagine it would not be included on that category.
When I tried the dtbo it deactivated my camera overlay so I think that i got the path wrong.

I’ll give you a heads up on the best scenario I find. Thanks.

@KevinFFF
Devkit, R36.4, jetson-io the python library? If yes when i tried to change the pull mode it said it wouldn’t be considered.
I need to test if by using busybox the value actually changes or if the circuit described on the TM only reads some parts of the register at boot and does not change dynamically the pin pull mode.

I’ll do some testing and come back with some sort of report. Thanks for the help.

8

sudo ./flash.sh -c bootloader/generic/cfg/flash_t234_qspi.xml jetson-agx-orin-devkit internal

Changed the value permanently when I look at the register with busybox. I did set the pull mode to None.
But when I branch the GPIO the circuit goes from 3.3V to 1.4V as if the pull_down of origin was still there.

I will measure my latencies with an STM32 and forego of the GPIO for a while. But I really want to understand that.

10

Can you please explain what you mean by “branch the GPIO”?

If your input signal is 3.3V I/O, then you should set the value below to 1 instead of 0. This pin is a 1.8V I/O but can accept 3.3V input or output to 3.3V with a pull up if this value is 1.

nvidia,io-high-voltage = <1>;

11

Hey Chris,

I have a simple circuit going on.

Its a Photodiode on reverse bias that swaps my NPN Transistor’s base for when its light or dark.

image
image517×421 29 KB

I have the GPIO on my pull up with 47k(not 4.7k as image) to 3.3V this pull up is connected to my Collector.
Emitter to GND.

Instead of a Switch I have my NPN Collector to MCU and Emitter to GND, and base connected to the Vout of the previous circuit.

image
image236×383 6.89 KB

I used 47k since that was the value of resistor for the PULL_UP for when I tried on pull-mode=PULL_UP.

When I look at the circuit on the Collector of my NPN I can see 3.26V when High and 0.3V when low (when I swap the Light intensity from dark to light).

When i branch/connect the GPIO this max value goes from 3.26 to 1.6V.

Changed the value you asked to <1> .

Now:
Value on register = 0b01100000 or 0x60
Value 3:2 set as 00 so NONE for pull-mode.
Value of bit 5 is 1 since reboot, so I imagine im on nvidia,io-high-voltage = <1>;

The way i used to set the value on the dt was changing the bootloader and using
$ sudo ./flash.sh -c bootloader/generic/cfg/flash_t234_qspi.xml jetson-agx-orin-devkit internal

image
image1465×1898 215 KB

Still giving the same behavior of 1.6V.

There might be something that I’m missing here on my circuit, or the circuit is still on PULL_DOWN even though the register says otherwise.
I might just need a buffer or a Schmitt Trigger circuit and it would work since I’m not really calculating any possibility of current leak neither using a trans-impedance stage , but that also means I need to buy up other components.

I am just using an ADC from my STM32 instead but if you have any ideas I can look into it.

Cordially,

TJ

13

The voltage drops to 1.6V when the signal is expected to remain at 3.26V?

Apologies - there is a level shifter from 1.8V to 3.3V on this pin on the Dev Kit carrier board. So the E_IO_HV for this pin should be cleared/0. You can see the schematics here, in P3737_A05_Concept_schematics.pdf: Jetson AGX Orin Series Developer Kit Carrier Board Design Files

To double check that the right pin is being configured, where are you accessing this pin? Is it pin 22 of the 40-pin expansion header?

1 Like
14

I’m doing the latency test with an STM32 now.
Yes it was dropping to 1.6V when it was supposed to remain at 3.26V.
Yes GPIO_17 on the pin 22 of the 40-pin expansion header.

I would need to test it again with the IO cleared but since I solved my problem with the STM we can close this thread.

Thanks a lot, next time I try using the GPIO on the jetson i’ll come back to the schematics.

Cordially,

TJ

16

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