Jetpack v. 32.6.1
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
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?
tegra19x-jetson_xavier_nx_module-gpio-default.dtsi (2.0 KB)
tegra19x-jetson_xavier_nx_module-padvoltage-default.dtsi (1.3 KB)
tegra19x-jetson_xavier_nx_module-pinmux.dtsi (54.4 KB)
tegra19x-mb1-prod-p3668-0001-a00.cfg (1022 Bytes)
it’s pinmux configuration to define the default pin status, you should complete the process by replaced the .cfg and also re-flash the board.
Hi @JerryChang thanks for the reply.
It seems like I had followed your advice.
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?
$ sudo cat /sys/kernel/debug/gpio
@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.
how about checking
/sys/kernel/debug/pinctrl/2430000.pinmux/ for the details.
@JerryChang unfortunately there is nothing within the directory /sys/kernel/debug … how is this normally populated?
did you fused your device to enable Jetson security?
@JerryChang - no I’ve not touched anything fuse or secureboot related I don’t believe
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.
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.
I’m not sure that it’s possible but have opened a separate thread to discuss that possibility here: overcoming-gpio-capacitive-loading-at-startup