Jetson Orin Nano: cannot find GPIO chip 2200000.gpio

[pintarj]

I'm porting a c++ project, that uses this library (v1.2.5), from Jetson Nano to an Jetson Orin Nano. The GPIO used to work on the Nano, but I'm having problems on the Orin. On the first GPIO::setmode(...) call I get this error:

terminate called after throwing an instance of 'std::runtime_error'
  what():  [Exception] [Exception] Cannot find GPIO chip 2200000.gpio (catched from: GPIO::get_data())
 (catched from: setmode())

Aborted (core dumped)

Latter i discovered that neither the sample code from this repository works on my Orin (I've tried with samples/simple_out.cpp). It produces the same error.

Not sure if problem is relative to this library, but I've tried NVIDIA/jetson-gpio and Rubberazer/JETGPIO on the same Orin and both works well.

[pintarj]

I noticed that this library looks into 2 folders for the GPIO chip (/sys/devices/ and /sys/devices/platform/). On my Orin the 2200000.gpio file is not present there, but in the /sys/bus/platform/devices/ folder. Found out because the NVIDIA's library looks in all those 3 folders.

[anath93]

@pintarj I am having same issue, are you on Jetpack 6 ? Were you able to solve after adding 3rd path ?

[Zhang-Senhua]

Any updates? I encounter the same problem

[pintarj]

@anath93 I'm on Jetpack 6.0, yes. I did not found out a solution using this library, and after few days of no replies, I opted for migrating to another library. Specifically Rubberazer/JETGPIO.

[anath93]

@anath93 I'm on Jetpack 6.0, yes. I did not found out a solution using this library, and after few days of no replies, I opted for migrating to another library. Specifically Rubberazer/JETGPIO.

Thank you for the solution, did you install that library on AGX Orin ? or Nano ?

[pintarj]

@anath93 I'm running a Jetson Orin Nano.

[anath93]

@pintarj Thank you ! I will try to fix this and keep this forum posted.

[anath93]

Hopefully this helps someone on AGX Orin side,

Option1 : Sysfs has been deprecated for GPIO in the upstream Kernel in Jetpack 6, now its libgpiod which is the new interfacing tool. To make this library work, on Jetson side compare Jetpack 5 vs 6 to see changes on defconfig side (CONFIG_EXPERT=y, CONFIG_SYSFS=y, and CONFIG_GPIO_SYSFS=y) for your platform and dtb's and build kernel accordingly which can be longer route but will bring back support to kernel.

Option 2: (Which I went with) sudo apt install gpiod link in cmake if using ROS or g++ to test it

Please refer to spreadsheet from jetson download for this to make sure weather pin is output or input or bidirectional and if you need to make changes please refer to pinmux section in manual gpiodetect (these will give you chip number you need in program) gpioinfo | grep "pin type coming from spreadsheet"

include

include

include

include

include

include

class gpio_comms { public: struct gpiod_chip chip; struct gpiod_line line_85; struct gpiod_line *line_43; struct gpiod_line_request_config config_85; struct gpiod_line_request_config config_43;

int estop;
int prox;

void init()
{
    // Open the GPIO chip
    chip = gpiod_chip_open("/dev/gpiochip0");
    if (!chip)
    {
        perror("Error opening GPIO chip");
        exit(EXIT_FAILURE);
    }

    // Get the GPIO line with offset 85
    line_85 = gpiod_chip_get_line(chip, 85);
    if (!line_85)
    {
        perror("Error getting GPIO line (offset 98)");
        gpiod_chip_close(chip);
        exit(EXIT_FAILURE);
    }

    // Initialize the configuration for line 85
    memset(&config_85, 0, sizeof(config_85));
    config_85.consumer = "gpio_comms_85";
    config_85.request_type = GPIOD_LINE_REQUEST_DIRECTION_INPUT;
    config_85.flags = 0;

    // Request the GPIO line with the provided configuration
    if (gpiod_line_request(line_85, &config_85, GPIOD_LINE_REQUEST_FLAG_ACTIVE_LOW) != 0)
    {
        perror("Error requesting GPIO line (offset 85)");
        gpiod_chip_close(chip);
        exit(EXIT_FAILURE);
    }

    // Get the GPIO line with offset 43
    line_43 = gpiod_chip_get_line(chip, 43);
    if (!line_43)
    {
        perror("Error getting GPIO line (offset 43)");
        gpiod_chip_close(chip);
        exit(EXIT_FAILURE);
    }

    // Initialize the configuration for line 43
    memset(&config_43, 0, sizeof(config_43));
    config_43.consumer = "gpio_comms_43";
    config_43.request_type = GPIOD_LINE_REQUEST_DIRECTION_INPUT;
    config_43.flags = 0;

    // Request the GPIO line with the provided configuration
    if (gpiod_line_request(line_43, &config_43, GPIOD_LINE_REQUEST_FLAG_ACTIVE_LOW) != 0)
    {
        perror("Error requesting GPIO line (offset 43)");
        gpiod_chip_close(chip);
        exit(EXIT_FAILURE);
    }
}

void readgpio()
{
    // Read the value of the GPIO line with offset 98
    int value_98 = gpiod_line_get_value(line_85);
    if (value_98 < 0)
    {
        perror("Error reading GPIO value (offset 98)");
        gpiod_chip_close(chip);
        exit(EXIT_FAILURE);
    }
    estop = value_98;

    // Read the value of the GPIO line with offset 43
    int value_43 = gpiod_line_get_value(line_43);
    if (value_43 < 0)
    {
        perror("Error reading GPIO value (offset 43)");
        gpiod_chip_close(chip);
        exit(EXIT_FAILURE);
    }
    prox = value_43;
}

void cleanup()
{
    // Release the GPIO lines and close the chip
    gpiod_line_release(line_85);
    gpiod_line_release(line_43);
    gpiod_chip_close(chip);
}

};

[pjueon]

Sorry for the late response. Did adding 3rd path to sysfs_prefixes fix the issue? If it didn't, I have no solution for this issue at the moment. Moving to gpio character device implementation (#95) is probably the right approach to fix this issue, but I don't know when I could do that.

[avanmalleghem]

Looks like it doesn't solve the issue :

terminate called after throwing an instance of 'std::runtime_error'
  what():  [Exception] could not open directory: /sys/bus/platform/devices/2200000.gpio/gpio (catched from: GPIO::get_data())

Aborted (core dumped)

[pjueon]

@avanmalleghem Thank you for the report. Like I mentioned, moving to gpio character device implementation (#95) is probably the right approach to fix this issue. Unfortunately my Jetson nano is broken, so I don't have any Jetson device at the moment :( When I get a new Jetson, I'll start working on #95