Jetson TX2 GPIO9_MOTION_INT (G14) pin strange pull-up behavior

I’ve been trying to debug an issue with GPIO9_MOTION_INT on the TX2. I am using a Jetpack 4.6.4 with the ConnectTech Astro carrier board. They claim that the connection is straight-thru with no circuitry but they won’t give me the schematics.
I use a jumper to connect G14 to a multimeter. It reads 1.8V, and I used echo in > /sys/class/gpio/gpio298/direction
to set it as an input.

It seems to have a pull-up enabled, but when I load it down with resistors (5k, 10k, 20k Ohms), I always get 1.1-1.2V on the pin.

I tried with with the standard dev board and a freshly restored image, and using a multimeter to probe pin 2 of Q28, and I get the same result (schematic below for reference). Even with the additinal 47k pull-up, I should be able to pull the pin much lower.

So it doesn’t look like a linear pull-up resistor, it’s more like a diode or something that’s clamping it to 1.2V. Does anyone know what’s going on? Or has anyone gotten this pin to be regular high impedance with no pull-ups?

I don’t think you set it as input successfully. Please change that with pinmux sheet first.

It’s set as input. I can read the input using sysfs if I drive it hard enough. But it takes like a 1k pull-down to bring the voltage low enough.

gpiochip1: GPIOs 256-319, parent: platform/c2f0000.gpio, tegra-gpio-aon:
gpio-272 ( |temp-alert ) in hi
gpio-298 ( |sysfs ) in hi
gpio-312 ( |Power ) in hi
gpio-313 ( |Volume Up ) in hi
gpio-314 ( |Volume Down ) in hi
gpio-315 ( |wifi-wake-ap ) in lo
gpio-316 ( |bt_host_wake ) in lo

Do you mean it can be pulled to low with 1k pull-down? The real pull-up could be stronger than 47k, so a stronger pull-down is necessary. In fact, to pull down a pin, shorting to GND is also acceptable.

I’m saying that the Jetson TX2 datasheet says the pull-up is 20kOhms, so it shouldn’t be this hard to pull it down, and the voltages should respond linearly to resistive loads. This all came about because I’m using a bidirectional voltage translator chip on my carrier board, and it didn’t work because the chip couldn’t drive the input, but it does fine with a different GPIO that should be the same pad type.

I’m saying that the datasheet isn’t describing that the actual behavior of the circuitry is behind this particular GPIO since there’s no configuration that should lead to behavior I’m seeing, so I’m either configuring it incorrectly, or this is an errata.

Are you really sure you are manipulating the right pin?
Since this is a custom carrier board, the pinmux setting is different from that of a DevKit.

If the pinmux had the pin set as an output, would you still be able to read the value using sysfs? Because I could set it as an input and read the value. Or does sysfs read the state of the pin regardless of whether it is set as an input or output? I can also use sysfs to set the output on that GPIO, and it works fine.

I’m actually using the ConnectTech Astro carrier board (, they confirmed that it’s a straight connection to the GPIO.

There is no update from you for a period, assuming this is not an issue any more.
Hence we are closing this topic. If need further support, please open a new one.

Sorry for the late response.
Is this still an issue to support? Any result can be shared?