Issue with GPIO Loopback Test Failed JP6.1 L4T36.4.0 with Orin Nano SOM 4GB Custom Carrier Board

Board : Custom Carrier Board

L4T : 36.4.0

JP : 6.1

SOM : Orin nano 4GB

Hi Nvidia Team,

I am currently performing a GPIO loopback test on my custom carrier board. For this test, I connected the PCC.00 and PCC.01 pins with a jumper wire. While I am able to set the GPIO values correctly, I am unable to retrieve the value back—it always returns zero.

I can confirm that the GPIOs worked fine under JP5.1.2. However, the issue has arisen in the latest JP versions.
We are using a custom libgpiod application, and I have verified that both input and output GPIOs are toggling by probing them with DSO.

Additionally, I referred to the following patch for guidance, but it did not resolve the issue:

Hi,
If you have applied the fix and the issue is still present, it may be another issue. Please share an approach to reproduce it on developer kit. So that we can set up and check.

Hi DaneLLL,

I am sharing the I’ve followed to help reproduce the issue on the Orin Nano Devkit.

Pin Configuration: I configured the following GPIOs as bidirectional in the Pinmux spreadsheet and generated the corresponding .dtsi file, replacing the generated settings:

GPIO1: PCC.00
GPIO2: PCC.01
GPIO3: PCC.02
GPIO4: PCC.03

Application Implementation: I developed a C command-line application using the libgpiod framework to control these GPIOs, including changing their direction and values. I can successfully modify the values and directions of the GPIOs, but I am unable to retrieve the correct value from the input GPIOs.

Additional Information:

I also tried using the gpioset and gpioget command-line tools, but faced the same issue. Specifically, when I set GPIO PCC.00 to output with a value of 1, I can successfully retrieve the value once using gpioget. However, on subsequent attempts, the value always returns as zero.

Additionally, in the Pinmux configuration, GPIO is correctly set, and it is not configured as SFIO, only as a GPIO.

Please let me know if you need any further details to help resolve this issue.

#include <stdio.h>
#include <unistd.h>
#include <gpiod.h>

#define GPIO2_PIN 12
#define GPIO3_PIN 13

#define GPIOD_LINE_DIRECTION_INPUT   0
#define GPIOD_LINE_DIRECTION_OUTPUT  1

// Function to initialize GPIO lines with error handling
struct gpiod_line *init_gpio(struct gpiod_chip *chip, int pin, int direction) {
    struct gpiod_line *line = gpiod_chip_get_line(chip, pin);
    if (!line) {
        perror("Unable to get GPIO line");
        return NULL;
    }

    // Request the line as input or output
    if (direction == GPIOD_LINE_DIRECTION_OUTPUT) {
        if (gpiod_line_request_output(line, "gpio_program", 0) < 0) {
            perror("Failed to request GPIO line as output");
            return NULL;
        }
    } else if (direction == GPIOD_LINE_DIRECTION_INPUT) {
        if (gpiod_line_request_input(line, "gpio_program_input") < 0) {
            perror("Failed to request GPIO line as input");
            return NULL;
        }
    }

    return line;
}

int main() {
    struct gpiod_chip *chip1;
    struct gpiod_line *line2, *line3;
    int value1, value2;

    // Open gpiochip1 for GPIO2 and GPIO3
    chip1 = gpiod_chip_open_by_name("gpiochip1");
    if (!chip1) {
	    perror("Unable to open GPIO chip 1");
	    return 1;
    }

    // Initialize GPIO2 as input, GPIO3 as output
    line2 = init_gpio(chip1, GPIO2_PIN, GPIOD_LINE_DIRECTION_INPUT);  // GPIO2 as input
    usleep(500000);
    line3 = init_gpio(chip1, GPIO3_PIN, GPIOD_LINE_DIRECTION_OUTPUT); // GPIO3 as output

    if (line2 && line3) {
	    value1 = gpiod_line_set_value(line3, 1); // Set GPIO3 to 1 (output)
	    usleep(500000);  // Allow signal to propagate
	    value1 = gpiod_line_get_value(line3); 
	    value2 = gpiod_line_get_value(line2); // Read GPIO2 (input)
	    printf("GPIO3 set to %d, GPIO2 value: %d\n", value1, value2);
    } else {
	    printf("Error in setting up GPIO lines\n");
    }

    // Clean up and release GPIO lines
    gpiod_line_release(line2);
    gpiod_line_release(line3);

    usleep(1000000);  // Wait a bit before the next iteration


    gpiod_chip_close(chip1);

    return 0;
}

Thanks

Hi @DaneLLL ,

Any Update on GPIO testing in devkit setup ?

Hi,
Please share how to set up developer kit. We are uncertain which two pins are configured from the sample application. And please share the command to build the sample.

Dependencies required to compile the program: sudo apt-get install libgpiod-dev
To compile the C program on the developer kit, use the following command:

gcc gpio_control.c -o gpio_control_exe -lgpiod

Let me know if anything else is needed.

Hi,
Please update the test code to use pins at 40-pin expansion header:

https://developer.nvidia.com/downloads/assets/embedded/secure/jetson/orin_nano/docs/jetson_orin_nano_devkit_carrier_board_specification_sp.pdf

Don’t see PCC.00(pin #126) and PCC.01(pin #127) be exposed on Orin Nano developer kit. Would be great if you can test with the pins at the expansion header.

Hi @DaneLLL ,
There’s nothing difficult about changing the test code. Please refer to the image below. The line numbers correspond to GPIO_PIN{NUM} in the test code. Similarly, there is a gpiochip that needs modification — tegra_main GPIOs are connected to gpiochip0, and tegra_aon GPIOs are connected to gpiochip1.

For your reference, as I mentioned earlier, we are able to toggle the GPIO and detect the changes using a DSO or multimeter. However, from a software perspective, we are unable to retrieve the value of the input

Hi,
We have some discussion and think it should work if the patch is applied correctly. We will try again on Orin Nano developer kit with the pins at expansion header.

The comment is a bit confusing since PCC.00 is set as input in the test sample but mentioned as output in the description.

Hi DaneLLL,

Thank you for your response. Please disregard the previous mention of the GPIO description, as it was a typo. I kindly request that you check with the Orin Nano Developer Kit at your earliest convenience. As our production timeline is approaching, we need to perform the GPIO loopback test to evaluate the GPIO functionality.

Sorry for interuppting. just wanted to update something what we observed in jetpack version 5.1.2 L4T version 35.4.1

We used sysfs to test gpios using eco and cat commands.
We used to get the written value, but on subsequent executing of cat command, we use to observe that the values was randomnly changing between 0 and 1.

Later analysis: we later analysed that could be due to the volatage variation which is causing this change as we used external cables and loop back connector to check values.
probably, due to the length of the cable and other issues, that value was not stable on the gpio.

Next, we started using multimeter to verify the gpio values, where the value we used to set 0 or 1 , used to immediately reflect a 0 v or 5 v. We considered this as the proper testing method.

1 Like

Hi Nagesh,

We checked both the DSO and the multimeter for GPIO toggling. However, I developed a test application to verify the GPIO functionality using loopback. In my case, the output GPIO is being sent to the input correctly, but in the software, it’s not reflecting properly in the latest Jetpack version

1 Like

Hi,
We have done loopback test on Orin Nano developer kit:

Jetson/L4T/peripheral/ - eLinux.org

Please try it and see if you can run this test successfully. Would like to align this test result first.

Hi DaneLL,

Thank you for performing the test. I’ll check it on my end as well.

I noticed in the link you shared for the loopback test that you configured one pin as input and one as output in the pinmuxdtsi file. I’d recommend trying a bidirectional configuration for the pins. This approach will ensure that the GPIO loopback test works as expected. For example, in the first iteration, you can configure gpio1 as input and gpio2 as output, and in the second iteration, configure gpio1 as output and gpio2 as input.

Please give this a try and let me know how it goes!

Hi,
So in your setup, the issue occurs when both pins are configured bidirectional? No issue when one pin is input and the other is output?

We’ve also configured them Bidirectional as you suggested.
Please refer to the following test results.

// check pinmux
$ sudo su
# busybox devmem 0x02430068
0x00000040
# busybox devmem 0x02430070
0x00000040

// Test 1: Control PQ.05 and Read PQ.06
# gpioinfo|grep -iE "PQ.05|PQ.06"
        line 105:      "PQ.05"       unused  output  active-high
        line 106:      "PQ.06"       unused  output  active-high
# gpioget `gpiofind "PQ.06"`
0
# gpioinfo|grep -iE "PQ.05|PQ.06"
        line 105:      "PQ.05"       unused  output  active-high
        line 106:      "PQ.06"       unused   input  active-high
# gpioset --mode=wait `gpiofind "PQ.05"`=1
(open another terminal)
# gpioget `gpiofind "PQ.06"`
1
(terminate gpioset process in previous terminal)

// Test 2: Control PQ.06 and Read PQ.05
# gpioget `gpiofind "PQ.05"`
1
# gpioget `gpiofind "PQ.06"`
1
# gpioinfo|grep -iE "PQ.05|PQ.06"
        line 105:      "PQ.05"       unused   input  active-high
        line 106:      "PQ.06"       unused   input  active-high
# gpioset --mode=wait `gpiofind "PQ.06"`=0
(open another terminal)
# gpioget `gpiofind "PQ.05"`
0
(terminate gpioset process in previous terminal)
# gpioinfo|grep -iE "PQ.05|PQ.06"
        line 105:      "PQ.05"       unused   input  active-high
        line 106:      "PQ.06"       unused  output  active-high

You would find that gpioget command will configure the direction as Input while gpioset command will configure the direction as Output.

Hi @KevinFFF and @DaneLLL,

Thank you for your support in resolving this issue. We performed a clean flash with the changes you mentioned, and we are now able to toggle the GPIOs by shorting them to test the loopback

1 Like

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