Hi there,
I have an Orin NX running JP 6.2 + JL 36.4.4. I have patched the kernel (to get GPIO working in the first place) successfully, and used the pinmux spreadsheet to configure pins 29 and 31 (GPIO01 and GPIO11) to output, drive 1, and 3.3V tolerance disabled.
When I run gpioinfo, I see my pins are successfully reconfigured to output, but they are active high, and when I test with a multimeter I get 0V unless I control the pins with gpiod or a similar utility.
I have tried a number of other combinations of pinmux settings to no avail. I have a buzzer that requires the pins to drive high and be active low from the moment the system boots. Is this a possibility? I assume there are ways I can configure the kernel post-flash to achieve my desired behaviour, but I do not want the system beeping while booting + waiting to load the kernel.
Any suggestions? I am relatively new to this stuff, but I am becoming pretty comfortable configuring the kernel, and don’t mind tinkering with device tree files manually if anyone can provide specific example (although I believe these only take effect after the pre-kernel bootload stage, and so probably won’t address the issue at hand).
I apologize if this has been answered before, but I have read the vast majority of pinmux-related forums on here and have not been able to find a solution thus far.
Some assistance with this would be much appreciated. Thank you in advance!
*** Please note that this reply is generated by LLM automatically ***
I’d be happy to help you with your issue!
First, let’s break down the problem:
- You have an Orin NX running JP 6.2 and JL 3.6.4.4.
- You’ve patched the kernel to get GPIO working and used the pinmux spreadsheet to configure pins 29 and 31 (GPIO01 and GPIO11) to output, drive 1, and 3.3V tolerance disabled.
- When you run
gpioinfo, you see that your pins are successfully reconfigured to output, but they are active high, and when you test with a multimeter, you get 0V unless you control the pins with gpiod or a similar utility.
- You want to configure the pins to drive high and be active low, so that your buzzer works as expected.
Now, let’s analyze the situation:
- The fact that you’re seeing 0V on the pins unless you control them with
gpiod or a similar utility suggests that the pins are being driven low by default.
- The pinmux spreadsheet settings you’ve applied should have configured the pins to output, drive 1, and 3.3V tolerance disabled. However, it seems that the pins are not being driven high as expected.
To achieve your desired behavior, you’ll need to configure the pins to drive high and be active low. Here are a few possible solutions:
- Check the pinmux spreadsheet settings: Double-check that you’ve correctly configured the pinmux spreadsheet settings for pins 29 and 31. Make sure that the “Drive” field is set to “1” and the “3.3V Tolerance Enable” field is set to “Disabled”.
- Use the
gpiod utility to set the pin direction: You can use the gpiod utility to set the pin direction to output and drive high. For example:
gpiod set pin-29 output high
gpiod set pin-31 output high
This should drive the pins high and make your buzzer work as expected.
3. Modify the device tree: You can modify the device tree to configure the pins to drive high and be active low. This will require modifying the tegra234-p2888-0001-p2822-0000.dtb file.
To modify the device tree, you’ll need to:
- Extract the device tree source code from the
tegra234-p2888-0001-p2822-0000.dtb file using the dtc utility.
- Modify the
gpio node in the device tree source code to configure the pins to drive high and be active low.
- Compile the modified device tree source code back into a
dtb file using the dtc utility.
- Flash the modified
dtb file to the Orin NX.
Here’s an example of how you might modify the device tree source code:
&gpio {
gpio@0 {
compatible = "nvidia,tegra234-gpio";
reg = <0x0 0x6000d000 0x0 0x1000>;
gpio-controller;
#gpio-cells = <2>;
gpio-pin-29 {
gpio-pin = <&gpio 29 0>;
drive-strength = <1>;
bias-disable;
};
gpio-pin-31 {
gpio-pin = <&gpio 31 0>;
drive-strength = <1>;
bias-disable;
};
};
};
This will configure pins 29 and 31 to drive high and be active low.
Note: Modifying the device tree can be complex and requires careful attention to detail. Make sure you understand the changes you’re making and test them thoroughly before flashing the modified device tree to the Orin NX.
I hope this helps! Let me know if you have any further questions or need more assistance.
*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***
This response is completely off the mark.
- pinmux spreadsheet settings are already exactly as described,
- This suggestion would only be systemd service-level at best, AND this is the incorrect command + syntax for gpioset.
- This is not the correct device tree file for my system, and my trust in the suggested dts code is 0.
I would appreciate a human response from someone who knows what they are talking about, if possible. Thanks.
Hi gkubiski,
Are you using the devkit or custom board for Orin NX?
Have you applied the following patch before control the pin?
40hdr - SPI1 gpio padctl register bit[10] effect by gpiod tools in JP6 - #20 by KevinFFF
Do you mean that your buzzer will alarm when the GPIO is LOW?
How do you control it? Do you have any custom driver for this work? Or you just use gpioset to control it manually?
Hi Kevin, thanks for the reply.
Yes, I am using the devkit carrier board, and I have applied that kernel patch. I am able to control my desired pins while using gpioset, the Python gpiod library., and even (once, after much pain, on an earlier version of my custom kernel) the Jetson GPIO library (despite it being deprecated for 6.2.1).
Yes, the buzzer alarms when the GPIO is low,. No custom drivers for this currently.
In the past we have used the i2c pins to control the buzzer successfully, as they drive high by default, However, we would definitely prefer to use GPIO pins if there is a way to properly configure them.
I am just hoping to drive these pins high ASAP upon boot, as the buzzer will otherwise go off immediately upon powering the machine until we either manually override with a utility like gpioset or a systemd service (or something similar) starts.
I also want to add that I have got my desired ~3.3V output (at boot time) from the pin using an external pull-up resistor. However, the pin is still detected as active-high when I run gpioinfo(with Drive 1 set in the pinmux spreadsheet). Trying to reconfigure it to active-low or to temporarily output 0V with gpioset/gpioget fails.
I am next going to try setting the external pull-up value in the pinmux respective to this resistor, but I highly doubt this would affect the logic level (from the system’s perspective) of these pins. Any info on this would be greatly appreciated. Thanks.
Okay, it seems you can control the GPIO for your buzzer to work currently.
And you want to control it LOW after boot up immediately.
Have you tried simply configuring the GPIO as Input/Drive 0 for this use case?
The pinmux/gpio dtsi will be loaded in early boot stage(i.e. MB1) so that your buzzer would work at that time.
For the active state, you may need a driver to configure the pin.
As you don’t have custom driver for this GPIO, I would suggest you simply control its state through gpioset command.
Hi Kevin. Thanks for getting back to me. After a lot of hardware troubleshooting, we’ve come to conclude our problem is twofold, and we’re just going to use the i2c pins (despite that being jank).
-
We’ve got an unnecessarily complex amount of logic between our buzzers and the GPIO pins we’re trying to control them with (unfortunately, not by our design - with an onboard microcontroller and dozens of other electrical components between the buzzers and gpio, with no access to a schematic - and largely out of our control in our current situation), so the voltage and current values between these buzzers and pins is not as would be expected in a typical (simple) low-trigger active buzzer circuit.
-
We have also concluded that (most likely) the GPIO pad for these pins is not rated to drain the amount of current supplied to our buzzers, on top of the current from the corresponding GPIO pins. So even after setting things up correctly (with our own buzzer circuits, on a simple breadboard), we cannot toggle our pins down to 0V (consistently) as desired.
Simply toggling the pins from high→low→high→low (etc) with gpiod or Jetson GPIO. with a simple (proper) buzzer circuit, we ultimately see our pins produce the following voltages with a multimeter: 3.3V (init)→0V→3.3→1.6→1.8→1.77→1.78→1.72→1.78→1.72, perpetually.
We are on a time crunch, and every re-flash takes like half a day of precise library installations/versioning in order for our software to function as desired, so at this time I sadly am giving up and using the i2c pins, which give us our desired behaviour (even though this is less than ideal).
We are also having issues controlling Pin 15 with PWM (whether with the pinmux configured for this alternate behaviour, or with a dtbo generated via jetson-io.py and merged with our dtb). Works fine + perfectly as desired when flashing with the jetson-orin-nano-devkit.conf board file, fails when using the jetson-orin-nano-super-maxn-nvme.conf file.
I wish I had more time to dedicate to figuring this out, but for now I have to shelf these issues and focus on more important things. Thanks for trying.
1 Like
Hi gkubiski,
Thanks for your update and let us know your status.
It seems your buzzer may work with square wave input so that PWM should help for your case.
Okay, if I2C interface can also make your buzzer work, then it is also fine.
If you want to do further debug on this issue in the future, please feel free to create another topic to discuss in details.
1 Like