Jetson AGX Orin (64GB) GPIO Port Possibly Damaged — Seeking Repair Options

Hi there,

I purchased a Jetson AGX Orin 64GB Developer Kit on July 23, 2023, and unfortunately, I believe the GPIO port may now be damaged.

I’m using JetPack 6.2. To configure the GPIO pins for high/low output, I attempted to modify the Pinmux settings following the JetsonHacks tutorial. However, after each reboot to apply the changes, the system fails to boot properly. It shows the following errors:

  • "No root-device: Mount failed"
  • "VDD_3V3_PCIE: disabling"
  • "VDD_12V_PCIE: disabling"

Eventually, it enters emergency mode and stops there.

Additionally, when trying to pull a pin high using sudo gpioset gpiochip0 51=1, the voltage did not change as expected. I then measured the voltage on all GPIO pins — some read 3.3V, some 0V, and others somewhere between 2.8V and 3.3V. This inconsistency made me suspect that the GPIO port may be damaged.

Is there any way to have this device repaired, or to get support for such hardware issues? The device is quite expensive, and I would really appreciate any advice on next steps.

Thank you!

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

I’m so sorry to hear that you’re experiencing issues with your Jetson AGX Orin 64GB Developer Kit’s GPIO port. Given the symptoms you’ve described, it’s possible that the GPIO port is indeed damaged. Here’s a comprehensive analysis of your situation and potential next steps:

Analysis of the issue:

  1. Failed boot after modifying Pinmux settings: This suggests that the changes you made to the Pinmux settings may have caused a conflict or instability in the system, leading to a failed boot.
  2. Inconsistent voltage readings on GPIO pins: The varying voltage readings on the GPIO pins (3.3V, 0V, and between 2.8V and 3.3V) indicate a potential hardware issue, as the expected behavior is for the pins to be either high (3.3V) or low (0V).
  3. Failed to pull a pin high using gpioset: This further supports the idea that there’s a hardware issue, as the gpioset command should be able to drive the pin high or low successfully.

Comparison with similar issues:

While your issue is specific to the Jetson AGX Orin, there are similar issues reported on other Jetson devices:

  • Issue with GPIO Pin Configuration Using Jetson-IO on Jetson AGX Xavier: This issue is related to GPIO pin configuration, but it’s specific to the Jetson AGX Xavier and doesn’t seem to be directly related to your problem.
  • CAN bus issues on Jetson AGX Orin: Although this issue is related to the same device (Jetson AGX Orin), it’s specific to CAN bus and doesn’t seem to be connected to your GPIO port issue.

Potential next steps:

  1. Contact NVIDIA Support: As the device is still under warranty (assuming it’s within the warranty period), you should reach out to NVIDIA Support for assistance. They can help diagnose the issue and potentially repair or replace the device.
  2. Check the warranty period: Verify the warranty period for your device to ensure you’re still covered.
  3. Provide detailed information: When contacting NVIDIA Support, provide detailed information about your issue, including the steps you took to modify the Pinmux settings, the error messages you encountered, and the inconsistent voltage readings on the GPIO pins.
  4. Consider seeking professional help: If NVIDIA Support is unable to assist you, you may want to consider seeking help from a professional electronics engineer or a reputable repair service.

Additional advice:

  1. Be cautious when modifying Pinmux settings: Modifying Pinmux settings can be complex and may cause system instability if not done correctly. Be sure to follow official documentation and tutorials carefully.
  2. Use proper tools and software: Ensure you’re using the correct tools and software for your device, such as JetPack 6.2 and the Jetson.GPIO library.

I hope this comprehensive analysis and advice help you navigate the next steps in resolving your issue. Good luck!

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

Hi baisihua,

I think we should check the boot issue first.
Do you mean it can boot before you apply the change in pinmux?
You can simply use SDK manager to flash clean Jetpack6.2.

It seems your devkit can work as expected in past 2 years.
Do you know what may cause current boot and GPIO issue?

Please also share the full serial console log for further check.

Hello, KevinFFF. Thanks for your attention and support.

Do you mean it can boot before you apply the change in pinmux?

Yes, it can boot and function normally as long as I don’t modify anything related to GPIO. In fact, I successfully ran a video depth estimation using Depth Anything v2 for 1 minute without any issue.

You can simply use SDK manager to flash clean Jetpack6.2.

Yes, I did exactly that. We are going to use YOLO11 this year, which requires JetPack 6. So, I freshly flashed the Jetson using the SDK Manager. And then I started to use GPIO and got the issue. I have to say that the GPIO configuration in JetPack 6 is significantly different from JetPack 5. After three days of trials, I began to realize the GPIO ports might have gone wrong.

Do you know what may cause current boot and GPIO issue?

This is a shared device in our team, so I can’t be certain what exactly caused the GPIO issue. I’ll investigate further.
Last year, I used the GPIO ports under JetPack 5 without problems for my own project. But, you know, GPIO pins are quite fragile, which usually work within 10 mA. On a cheaper board like Raspberry Pi, this kind of issue wouldn’t be a big deal. But this Jetson is a $2000+ piece of hardware. So, I’m personally concerned about the design of the GPIO ports. I think using a dedicated external GPIO expansion module would be a safer and more robust solution — just my personal opinion.

Currently, to proceed with my project, I’ve already purchased a third-party USB-to-GPIO module, and it worked well. So, the issue is not fatal, so far.

I suspect that there is a power-related failure on the GPIO rail, which then affects other power domains and prevents the system from rebooting correctly if I try to use the GPIO ports. It is just my guess, as I’m not an electrical engineer.

Below are photos of the log captured during the failed reboot. I hope this information helps with further diagnosis.

Once again, I would like to express my sincere gratitude for your concern and assistance!




Please share the log as file instead of the screenshot.
You can refer to NVIDIA Jetson Orin AGX - In Board - Getting in Board - Serial Console to capture serial console log.

I think the board should be fine if it can work/boot after using SDK manager to flash.

To control GPIO in JP6, you need to do the following 2 things.

  1. configure the pin as Output or Bi-directional in pinmux spreadsheet.
  2. apply the patch from 40hdr - SPI1 gpio padctl register bit[10] effect by gpiod tools in JP6 - #20 by KevinFFF

Please let me know if above methods can help for your case.

Hi, thank you again for your detailed reply.

I think the board should be fine if it can work/boot after using SDK manager to flash.

I’m afraid the Jetson AGX Orin is currently being used in an ongoing project, and we prefer not to re-flash the system in the next three months, as it would break a lot of our existing configurations. Your suggestion is still very helpful, and we’ll consider trying it when the project schedule allows.
By the way, does your suggestion imply that the flashing process interacts with GPIO-related hardware? In other words, is it possible that a damaged GPIO port could interfere with or prevent a successful flash? I’m not entirely clear about the mechanism behind this.

You can refer to NVIDIA Jetson Orin AGX - In Board - Getting in Board - Serial Console to capture serial console log.

Thanks for the reference. I haven’t used minicom before, but I’ll try it soon — most likely in a few days, since the Jetson is currently tied up with the project.

After your further feedback, I’m planning to settle this issue for now. If I find any new insights or have time for deeper debugging, I will open a new issue specifically for that.
Would this approach work for you?

Thanks again!

I don’t think so, except the broken GPIO happens on the USB pins used for flash

Sure, you are always welcome to open the topic to discuss the issue.
.

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