I’m looking to try and set the default value of GPIO pins of PT.05, PY.04, PDD.00 and PCC.07 to output low on the Jetson Xavier NX development board.
I have a custom root file system that I am flashing using the script provided in the jetpack driver package (BSP)
Before flashing I have utilised the Pinmux mapping spreadsheet to generate the dtsi files attached.
I converted the dtsi files using the pinmux-dts2cfg.py script producing tegra19x-mb1-pinmux-p3668-a01.cfg (attached) and replaced the default .cfg in Linux_for_Tegra/bootloader/t186ref/BCT.
It doesn’t appear that the gpio are being set however which I verified by trying to set the pins high by default, again with no success.
I can set gpio high/low when the system has boot using the NVIDIA python gpio library
Questions:
Is this process for setting the GPIO correct? Have I made an error in the dtsi / cfg files?
I notice that there isn’t a directory /sys/kernal/debug/gpio on the running the flashed dev board; does this point to an issue?
I replaced the cfg in the Linux_for_Tegra/bootloader/t186ref/BCT before I re-flashed the device.
The .cfg file was pulled into the Linux_for_Tegra/bootloader/ folder during flash and locked out so all seemed to be good in that regard.
Is there a way to query the jetson for its default gpio settings after the system has flashed?
@JerryChang as mentioned there is nothing in that particular directory, does that point to an issue or a missing dependency?
We are using a base arm64v8/ubuntu version which we apply the NVIDIA binaries to plus a number of other libraries specific to our needs. The image seems to work fine otherwise, we have no issues communicating via the serial using UART1 for instance.
are you only custom root file system, or, you are also customize the board?
since this usually a hardware related issue, please also access Jetson Xavier NX Product Design Guide to review your hardware design if necessary.
BTW,
did you really check that path (/sys/kernel/debug) as root? you should use sudo -i to enter super-user mode for confirmation.
I’ve now managed to fix my image regarding the /sys/kernel/debug path.
It seems I was getting a bug similar to that in corrupted-kernel-headers-package-in-l4t-32-6-1. I downloaded the BSP through the download page instead of the SDK and this error seems to have been removed so I now have access to files in the /sys/kernel/debug folder
It turns out that the setting of the default value was actually working and I was seeing similar to this post jetson-nano-gpio-example-problem
When setting the pins to default high, the cheap DMM I was using was loading the GPIO pins pulling them low. This was only verified by scoping the pins during the carrier board reset which showed that they begun high and when probed with DMM were driven low. It was even the case that insertion of the scope probes (x10) at times was possible to drive the pins low!
This factor is unfortunate as it doesn’t help with our application as we require the pins held low. It seems like a bit of capacitive coupling can actually cause the pins to float.
When I use the Jetson.GPIO library however it seems like by setting the GPIO via sysfs the pins remain high/low when probed with the DMM. I would like that similar drive strength when setting the default pin configuration.