Modify Pinmux/GPIO functions - custom Jetson Orin NX carrier

Robotics & Edge Computing Jetson & Embedded Systems Jetson Orin NX
, ,
1

I have a custom Orin NX (16GB) carrier card with only a few overlays provided by the board manufacturer. I want to repurpose 2 Jetson I/O pins that are currently UART (uart2_tx_px4 and uart_rx_px5) to GPIO inputs. I also want to repurpose 1 Jetson I/O pin that is currently GPIO input (soc_gpio39_pn1) to a PWM output. I have used the Jetson Orin Nano&NX Pinmux HDMI tab of the pinmux spreadsheet to attempt to determine what the overlay would look like (changes only … I have the full DTSI file if needed, but I didn’t see the equivalent file in the source tree to replace):

gpio.dtsi (added to gpio@2200000…gpio_main_default…gpio-input):

			TEGRA234_MAIN_GPIO(X, 4)
			TEGRA234_MAIN_GPIO(X, 5)

gpio.dtsi (removed from gpio@2200000…gpio_main_default…gpio-input):

			TEGRA234_MAIN_GPIO(N, 1)

pinmux.dsti (changed):

			uart2_tx_px4 {
				nvidia,pins = "uart2_tx_px4";
				nvidia,function = "rsvd1";
				nvidia,pull = <TEGRA_PIN_PULL_NONE>;
				nvidia,tristate = <TEGRA_PIN_ENABLE>;
				nvidia,enable-input = <TEGRA_PIN_ENABLE>;
				nvidia,io-high-voltage = <TEGRA_PIN_DISABLE>;
				nvidia,lpdr = <TEGRA_PIN_DISABLE>;
			};

			uart2_rx_px5 {
				nvidia,pins = "uart2_rx_px5";
				nvidia,function = "rsvd1";
				nvidia,pull = <TEGRA_PIN_PULL_NONE>;
				nvidia,tristate = <TEGRA_PIN_ENABLE>;
				nvidia,enable-input = <TEGRA_PIN_ENABLE>;
				nvidia,io-high-voltage = <TEGRA_PIN_DISABLE>;
				nvidia,lpdr = <TEGRA_PIN_DISABLE>;
			};

...

			soc_gpio39_pn1 {
				nvidia,pins = "soc_gpio39_pn1";
				nvidia,function = "gp";
				nvidia,pull = <TEGRA_PIN_PULL_NONE>;
				nvidia,tristate = <TEGRA_PIN_DISABLE>;
				nvidia,enable-input = <TEGRA_PIN_DISABLE>;
				nvidia,lpdr = <TEGRA_PIN_DISABLE>;
			};

What are the steps to incorporate these changes into the DTB that is used at boot time and/or create a overlay with these changes (and have that overlay recognized)?

Configuration/build Details:

Jetpack 36.4.3

cat /etc/nv_tegra_release

# R36 (release), REVISION: 4.3, GCID: 38968081, BOARD: generic, EABI: aarch64, DATE: Wed Jan  8 01:49:37 UTC 2025
# KERNEL_VARIANT: oot
TARGET_USERSPACE_LIB_DIR=nvidia
TARGET_USERSPACE_LIB_DIR_PATH=usr/lib/aarch64-linux-gnu/nvidia

ls /boot/dtb

kernel_tegra234-p3768-0000+p3767-0000-nv.dtb

uname -a

Linux custom-board 5.15.148-tegra #1 SMP PREEMPT Tue Jan 7 17:14:38 PST 2025 aarch64 aarch64 aarch64 GNU/Linux

sudo apt-cache show nvidia-jetpack

Package: nvidia-jetpack
Source: nvidia-jetpack (6.2.1)
Version: 6.2.1+b38
Architecture: arm64
Maintainer: NVIDIA Corporation
Installed-Size: 194
Depends: nvidia-jetpack-runtime (= 6.2.1+b38), nvidia-jetpack-dev (= 6.2.1+b38)
Homepage: http://developer.nvidia.com/jetson
Priority: standard
Section: metapackages
Filename: pool/main/n/nvidia-jetpack/nvidia-jetpack_6.2.1+b38_arm64.deb
Size: 29300
SHA256: dd9cb893fbe7f80d2c2348b268f17c8140b18b9dbb674fa8d79facfaa2050c53
SHA1: dc630f213f9afcb6f67c65234df7ad5c019edb9c
MD5sum: 9c8dc61bdab2b816dcc7cd253bcf6482
Description: NVIDIA Jetpack Meta Package
Description-md5: ad1462289bdbc54909ae109d1d32c0a8

Package: nvidia-jetpack
Source: nvidia-jetpack (6.2)
Version: 6.2+b77
Architecture: arm64
Maintainer: NVIDIA Corporation
Installed-Size: 194
Depends: nvidia-jetpack-runtime (= 6.2+b77), nvidia-jetpack-dev (= 6.2+b77)
Homepage: http://developer.nvidia.com/jetson
Priority: standard
Section: metapackages
Filename: pool/main/n/nvidia-jetpack/nvidia-jetpack_6.2+b77_arm64.deb
Size: 29298
SHA256: 70553d4b5a802057f9436677ef8ce255db386fd3b5d24ff2c0a8ec0e485c59cd
SHA1: 9deab64d12eef0e788471e05856c84bf2a0cf6e6
MD5sum: 4db65dc36434fe1f84176843384aee23
Description: NVIDIA Jetpack Meta Package
Description-md5: ad1462289bdbc54909ae109d1d32c0a8

Package: nvidia-jetpack
Source: nvidia-jetpack (6.1)
Version: 6.1+b123
Architecture: arm64
Maintainer: NVIDIA Corporation
Installed-Size: 194
Depends: nvidia-jetpack-runtime (= 6.1+b123), nvidia-jetpack-dev (= 6.1+b123)
Homepage: http://developer.nvidia.com/jetson
Priority: standard
Section: metapackages
Filename: pool/main/n/nvidia-jetpack/nvidia-jetpack_6.1+b123_arm64.deb
Size: 29312
SHA256: b6475a6108aeabc5b16af7c102162b7c46c36361239fef6293535d05ee2c2929
SHA1: f0984a6272c8f3a70ae14cb2ca6716b8c1a09543
MD5sum: a167745e1d88a8d7597454c8003fa9a4
Description: NVIDIA Jetpack Meta Package
Description-md5: ad1462289bdbc54909ae109d1d32c0a8

Thanks in advance!

2

*** Please note that this reply is generated by LLM automatically ***

To incorporate the changes you’ve made to the pinmux configuration into the Device Tree Binary (DTB) used at boot time, you’ll need to follow these steps:

  1. Create a custom Device Tree Source (DTS) file: You’ve already modified the pinmux configuration using the Jetson Orin Nano/NX Pinmux spreadsheet. Now, you need to create a custom DTS file that reflects these changes. You can start with the existing tegra194-p3768-0000-p3509-0000.dts file (or the equivalent file for your specific board) and modify it to include your changes.
  2. Update the GPIO configuration: In your custom DTS file, update the GPIO configuration to reflect the changes you’ve made. Specifically, you’ll need to:
    • Remove the gpio2-2000000/gpio/main/default/gpio-input node for the pins you want to repurpose as GPIO inputs (uart2txpx4 and uart2rxpx5).
    • Add a new gpio2-2000000/gpio/main/default/gpio-input node for the pins you want to repurpose as GPIO inputs.
    • Update the gpio2-2000000/gpio/main/default/gpio-output node to reflect the changes for the pin you want to repurpose as a PWM output (socgpio39pn1).
  3. Compile the custom DTS file: Use the dtc compiler to compile your custom DTS file into a DTB file. You can do this using the following command:
dtc -I dts -O dtb -o custom.dtb custom.dts
  1. Copy the custom DTB file to the boot directory: Copy the compiled custom DTB file to the /boot directory on your Jetson Orin NX module:
sudo cp custom.dtb /boot/
  1. Update the boot configuration: Update the boot configuration to use your custom DTB file. You can do this by modifying the boot/extlinux.conf file to include the following line:
FDT /boot/custom.dtb
  1. Reboot the system: Reboot your Jetson Orin NX module to apply the changes.

Alternatively, you can create a custom overlay file that includes your changes and apply it to the existing DTB file. To do this:

  1. Create a custom overlay file: Create a new file (e.g., custom-overlay.dts) that includes only the changes you’ve made to the pinmux configuration.
  2. Compile the overlay file: Use the dtc compiler to compile your custom overlay file into a DTBO file:
dtc -I dts -O dtbo -o custom-overlay.dtbo custom-overlay.dts
  1. Copy the overlay file to the boot directory: Copy the compiled overlay file to the /boot directory on your Jetson Orin NX module:
sudo cp custom-overlay.dtbo /boot/
  1. Apply the overlay: Apply the overlay to the existing DTB file using the following command:
sudo dtbo apply custom-overlay.dtbo
  1. Reboot the system: Reboot your Jetson Orin NX module to apply the changes.

In both cases, you’ll need to ensure that the changes you’ve made are compatible with the existing hardware and software configuration on your Jetson Orin NX module.

Comparison with other approaches:

  • Using the gpio command to configure GPIO pins at runtime is not recommended, as it may not persist across reboots.
  • Modifying the gpiodtsi file directly is not recommended, as it may not be compatible with future updates to the Jetson Orin NX software.
  • Creating a custom overlay file is a more flexible approach, as it allows you to apply changes to the DTB file without modifying the underlying DTS file.

Additional notes:

  • Make sure to test your changes thoroughly to ensure that they do not cause any issues with the system.
  • If you’re using a custom carrier board, you may need to modify the pinmux configuration to match the specific pinout of your board.
  • If you’re using a different version of JetPack, the steps above may vary slightly.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

5

Hi flybyya23,

The configuration in pinmux and gpio dtsi are loaded in early boot stage(i.e. MB1) rather than kernel so that they will not be included in kernel DTB.

Is this pinmux spreadsheet provided by your vendor?
If not, please request them for this as the board is developed by them.

6

They do not provide a pinmux spreadsheet, but I generated an unmodified pinmux/gpio DTSI file from NVIDIAs spreadsheet and the files here in the build match what I generated:

/Linux_for_Tegra/bootloader/tegra234-mb1-bct-gpio-p3767-hdmi-a03.dtsi
/Linux_for_Tegra/bootloader/generic/BCT/tegra234-mb1-bct-pinmux-p3767-hdmi-a03.dtsi

When I perform a flash operation, I see the pinmux file being pulled in but I don’t see the gpio file being processed (in the console output where I run the flash command). I also don’t see the gpio file being included in the board.conf file.

Here is my flash command:

sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_external.xml -p "-c bootloader/generic/cfg/flash_t234_qspi.xml --no-systemimg" --network usb0 my_custom_board external

and my_custom_board.conf:

source "${LDK_DIR}/p3509-a02-p3767-0000.conf"

OVERLAY_DTB_FILE+=",tegra234-p3767-my_custom_board-model.dtbo,tegra234-p3767-disable-display.dtbo,tegra234-p3767-enable-serial.dtbo";

The overlays only modify the model, enable a serial port, and disable the display (this is headless).

When I make the modifications directly to these files, I don’t notice a change when I query the pins via gpioinfo.

The first thing I see that I question with the output of the pinmux spreadsheet is that when I change uart2_tx_px4 and uart2_rx_px5 to be GPIO instead of UART, the generated DTSI marks its function as “rsvd1”. Should it mark it as GP? These pins were marked as “input” according to gpioinfo prior to the reflash, but maybe that was because they were allocated to SFIO (UART) prior and gpioinfo wouldn’t be handling those pins.

At a minimum I thought gpioinfo should show soc_gpio39_pn1 as an output with the changes above, but I’m not seeing that?

Attached is the result of retrieving the device-tree from /proc:

dtc -I fs -O dts -o extracted.dts /proc/device-tree

Further questions:

(1) How does /Linux_for_Tegra/bootloader/tegra234-mb1-bct-gpio-p3767-hdmi-a03.dtsi get processed and loaded in the build/flash process? As you can see from my flash command specifying my_custom_board.conf, it immediately specifies an NVIDIA conf which should include this GPIO DTSI at some point?

(2) Curiosity, the addresses of the GPIO controllers in that DTSI file are 2200000, C2F0000, and 9250000. I only see the 2200000 address in the system address map in the Orin TRM (Orin-TRM_DP10508002_v1.2p.pdf). Do you know where the C2F0000 and 9250000 addresses are documented?

(3) Other than extracting the device tree from /proc or querying gpioinfo, is there another method to determine the GPIO configuration of these pins from a running board (and therefore being able to see the configuration changes)?

7

Hello @flybyya23,

Hope everything is going great!

Allow me to jump into the conversation.

  1. I believe tegra234-mb1-bct-gpio-p3767-hdmi-a03.dtsi should be “imported” by the tegra234-mb1-bct-pinmux-p3767-hdmi-a03.dtsi. You can open the pinmux dtsi and check the first lines, and there should be an import with your gpio dtsi. That is how the board config only sets the pinmux dtsi but also pulls-in the GPIO defaults.

  2. For this question, I don’t really have an answer. I will reach back out if I see something though.

  3. I would suggest you read the pinmux registers with devmem. Check this out, I something I found out very recently in one of our client’s projects and I believe is incredibly useful: changing-the-pinmux. You can use a tool called devmem to read and write the pinmux registers dynamically. This will allow you not only to test changes before baking them into the pinmux dtsi but to also verify pin configuration is correct after flashing.

Hope this helps.
Please keep me posted, and don’t hesitate to reach out if you need further support.

best regards,
Andrew
Embedded Software Engineer at ProventusNova

8

Thanks @proventusnova and @KevinFFF.

Update. I was able to confirm that include @proventusnova thanks. I haven’t tried devmem yet, but I was able to use the changes in the 1st post and use PN.01 as a PWM.

I was also able to use PX.05 (uart2_rx_px5) as an input, though technically it was already an input.

However, it still looks like PX.04 (uart2_tx_px4) is configured as an output - it is measured to be driven to 0V (ish) and I would expect it to be high.

I did have PX.06/PX.07 still configured for UARTB, so I’m wondering if there’s some logic somewhere that depends on all UARTB pins to be set as GP otherwise it’s going to ignore my configuration for PX.04/PX.05. Seems like a long shot but I’m going to try it.

Otherwise, any ideas on why this wouldn’t make PX.04 (uart2_tx_px4) a GPIO input?

			uart2_tx_px4 {
				nvidia,pins = "uart2_tx_px4";
				nvidia,function = "gp";
				nvidia,pull = <TEGRA_PIN_PULL_NONE>;
				nvidia,tristate = <TEGRA_PIN_ENABLE>;
				nvidia,enable-input = <TEGRA_PIN_ENABLE>;
				nvidia,io-high-voltage = <TEGRA_PIN_DISABLE>;
				nvidia,lpdr = <TEGRA_PIN_DISABLE>;
			};
9

Additional update. I tried the busybox devmem process but was unable to read the register address the address I computed for PX.04:

base address 0x2430000 (PADCTL_A0 for GP3)
port offset 0x114 (webpage)
pin offset 4 (PX.04)

therefore I believe the appropriate address for PX.04 is 0x02430118

$ sudo busybox devmem 0x02430118
[ 8292.128072] CPU:0, Error: cbb-fabric@0x13a00000, irq=178
0xFFFFFFFF
[ 8292.128083] **************************************
[ 8292.128085] CPU:0, Error:cbb-fabric, Errmon:2
[ 8292.128092]    Error Code            : SLAVE_ERR
[ 8292.128100]
[ 8292.128102]    Error Code            : SLAVE_ERR
[ 8292.128104]    MASTER_ID             : CCPLEX
[ 8292.128106]    Address               : 0x2430118
[ 8292.128108]    Cache                 : 0x0 -- Device Non-Bufferable
[ 8292.128112]    Protection            : 0x2 -- Unprivileged, Non-Secure, Data
[ 8292.128115]    Access_Type           : Read
[ 8292.128117]    Access_ID             : 0x17
[ 8292.128119]    Fabric                : cbb-fabric
[ 8292.128121]    Slave_Id              : 0x2e
[ 8292.128122]    Burst_length          : 0x0
[ 8292.128123]    Burst_type            : 0x1
[ 8292.128124]    Beat_size             : 0x2
[ 8292.128125]    VQC                   : 0x0
[ 8292.128126]    GRPSEC                : 0x7e
[ 8292.128127]    FALCONSEC             : 0x0
[ 8292.128128]    Slave                 : AXI2APB_28
[ 8292.128130]  **************************200******opilot@ec[ 8hop8148] WARi:~$ 213 at drivers/soc/tegra/cbb/tegra234-cbb.c:608 tegra234_cbb_isr+0x144/0x190
[ 8292.128386] ---[ end trace 970a5b45b5d94c88 ]---

Is devmem supposed to work in this address space?

10

Update 3! I found this method to check configuration:

cat /sys/kernel/debug/pinctrl/2430000.pinmux/pinconf-groups | grep px4 -A 14

88 (uart2_tx_px4):
        pull=0
        tristate=0
        enable-input=1
        open-drain=0
        io-reset=0
        rcv-sel=0
        io-hv=0
        schmitt=0
        pull-down-strength=0
        pull-up-strength=0
        drive-type=0
        gpio-mode=1
        function=uartb


cat /sys/kernel/debug/pinctrl/2430000.pinmux/pinconf-groups | grep px5 -A 14

89 (uart2_rx_px5):
        pull=0
        tristate=0
        enable-input=1
        open-drain=0
        io-reset=0
        rcv-sel=0
        io-hv=0
        schmitt=0
        pull-down-strength=0
        pull-up-strength=0
        drive-type=0
        gpio-mode=0
        function=uartb

This is after I attempted to set these pins as bidirectional. PX.04 still not behaving. I noticed that “function” is still uartb for both and gpio-mode=1 for PX.04 (not working as input) and gpio-mode=0 for PX.05 (working as input with interrupts verified with gpiomon).

11

The pinmux register for PX.04(UART2_TX) is 0x0243d050.
Please run the following command instead.

$ sudo busybox devmem 0x0243d050

Have you confirmed that the pinmux dtsi has been applied correctly? (i.e. do you see this dtsi been used in flash log?)

12

@KevinFFF Thanks. I think I see how you got to that address so I’ll document for myself, though I have a question along the way. I am using the method here: Jetson Orin NX and Nano Series — NVIDIA Jetson Linux Developer Guide.

None of the names in the pinmux spreadsheet corresponded to anything in the TRM that I could find (verbatim using search). But since it’s in the “G2” group, I assume the PADCTL register is PADCTL_G2_UART2_TX with an offset of 0x50. Then the PADCTL_G2 refers to PADCTL_A13 in the system address map (base 0x0243d000).

For the data below, I started with my current iteration of the DTSI entry (I was attempting bidirectional):

                        uart2_tx_px4 {
                                nvidia,pins = "uart2_tx_px4";
                                nvidia,function = "rsvd1";
                                nvidia,pull = <TEGRA_PIN_PULL_NONE>;
                                nvidia,tristate = <TEGRA_PIN_DISABLE>;
                                nvidia,enable-input = <TEGRA_PIN_ENABLE>;
                                nvidia,io-high-voltage = <TEGRA_PIN_DISABLE>;
                                nvidia,lpdr = <TEGRA_PIN_DISABLE>;
                        };

Immediately after boot:

$ sudo busybox devmem 0x0243d050
0x00000041

$ sudo cat /sys/kernel/debug/pinctrl/2430000.pinmux/pinconf-groups | grep px4 -A 14
88 (uart2_tx_px4):
        pull=0
        tristate=0
        enable-input=1
        open-drain=1
        io-reset=1
        rcv-sel=1
        io-hv=1
        schmitt=0
        pull-down-strength=0
        pull-up-strength=0
        drive-type=0
        gpio-mode=0
        function=rsvd1

        line 118:      "PX.04"       unused   input  active-high

I’m not sure why pinconf-groups shows open-drain and io-hv enabled, but this would confirm that my DTSI changes are being pulled in: function changed from uartb to rsvd1.

In this state I’m measuring ~0V on the pin. I attempted to enable the pullup - I would have expected this to pull the pin high:

$ sudo busybox devmem 0x0243d050 w 0x049
$ sudo busybox devmem 0x0243d050
0x00000049

but the pin stays at ~0V (measuring with scope). I then tried setting it to an output and driving it high:

$ sudo busybox devmem 0x0243d050 w 0x001
$ sudo busybox devmem 0x0243d050
0x00000001
$ sudo gpiofind "PX.04"
gpiochip0 118
$ sudo gpioset gpiochip0 118=1

but the pin again stays at ~0V. The only way I was able to get it to drive high was the following sequence:

$ sudo busybox devmem 0x0243d050 w 0x001
$ sudo busybox devmem 0x0243d050
0x00000001
$ sudo gpioset gpiochip0 119=1
$ sudo busybox devmem 0x0243d050
0x00000401
$ sudo busybox devmem 0x0243d050
0x00000401
$ sudo busybox devmem 0x0243d050 w 0x001
$ sudo busybox devmem 0x0243d050
0x00000001

It’s only with the second write to the PADCTL register (when gpioset is used to drive it high before it’s set to an ouptut) that I can get the pin high. But at least this indicates the chip can get to where the pin is in a high state, I have the right pin on the connector, and external circuitry isn’t holding it back (both PX.04 and PX.05 are connected to an external connector via 1.8V-3.3V level shifter exactly the same). BTW, PX.05 (PADCTL 0x0243d050) behaves the same as PX.04 when operating as an output like this - I expect this has something to do with gpiod behavior when going behind it with devmem. Do you know the gpio control register addresses for reading/writing for these pins?

edit: I noticed the pinmux spreadsheet has a note for both of these pins “Buffered on module to keep connected devices from affecting state of the pin during power-on as it is one of the SoC stap pins.” [assume “stap” is supposed to be “strap”, but straight from the pinmux spreadsheet]. This buffering is on the Orin NX module/SODIMM? Is the buffering different from PX.04/PX.05?

With all this in mind, can you see why I can’t get PX.04 to behave like PX.05?

PX.05: defaults HIGH and I can get a rising edge interrupt when tied to a PWM output (using PN.01 to drive a PWM), verified using gpiomon.

PX.04: defaults LOW and when (seemingly) configured as an input, I can’t get a rising edge interrupt when tied to a PWM.

End use case: I need these specific 2 GPIOs (because they are connected to an external connector on our board) to generate rising edge interrupts on a pulsed input.

13

Maybe you can also refer to the following thread for the address for both PADCTRL and DRA.
Calculating/Getting register adresses of gpio pins - #10 by KevinFFF

Have you configured it as Input/Int PU in pinmux spreadsheet as following?
image

How do you configure this pin as interrupt? In device tree? If so, please share with us for further check.

14

@KevinFFF I have been using GPIO3_PX.04/Input with Req. Initial State box empty. I had tried enabling pullup with dev mem (setting 0x049) with no luck. I attempted a device tree with your exact settings (for both PX.05 and PX.04) and I have the same problem. PX.04 comes up low and a PWM on PN.01 (back fed through external level converter) is unable to drive PX.04 correctly (PX.04 is affecting signal when PN.01 is attempting to drive high). PX.05 comes up high and a PWM on PN.01 (back fed through external level converter) works fine.

$ sudo busybox devmem 0x0243d058
0x00000059
$ sudo busybox devmem 0x0243d050
0x00000059

Not specifically - PX.05 worked without any changes so I was thinking PX.04 would have already been configured as well if in GPIO mode. I haven’t done an interrupt configuration yet - an you advise how to enable the interrupt on PX.04 in the device tree?

15

Using devmem to configure the register will only valid in runtime. (i.e. it will be invalid in next boot)

PX.04 and PX.05 should have similar behavior, please let me check with HW folk.

17

Understand. That was a test. It’s now configured that way in the device tree. This is what I have after boot:

$ sudo busybox devmem 0x0243d058
0x00000059

@KevinFFF, Thanks. Please let me know as soon as practical. I attempted to pull up the external pin to 3.3V (on the 3.3V side of the level shifter) with a 10k external pullup and it’s still being driven low.

19

PX.04 is uart2_tx_px4 and PX.05 is uart2_rx_px5. We suppose PX.05 worked as an input for the user since RX is already usually an input. We would recommend for the pinmux table to change both to GPIO in Customer Usage/column AT, Input in Pin Direction/column AU, and Z in Req. Initial State/column AV.

20

I found the problem with this particular pin. In the design guide, https://developer.nvidia.com/downloads/jetson-orin-nx-series-nano-series-design-guide:

image
image621×439 80.8 KB

therefore PX.04 / GP32_UART2_TXD / UART0_TXD should not be used as GPIO (cannot be used as input due to output-only buffer, probably could be used as a GPIO output, but still “subject to change” so probably shouldn’t be used as GPIO at all.

Recommend the pinmux spreadsheet be updated for these types of pins - either don’t allow selecting as GPIO, force GPIO/Output only (don’t allow input), or at least a note.

1 Like