Things I have done so far:
I made an image for Jetson nano 4gb variant using the Compiling Custom Kernel Modules on the Jetson Nano | Kevin's Blog . I have enabled the following options in pic below from the menuconfig.
Then I moved to set up the pins from the jetson-io. I configured them and rebooted the system. The spi is available in /dev and pins are configured.
My Situation at the moment
After configuring the pins I rebooted the system as per the options to apply the changes of jetson-io.
I shorted the MISO and MOSI and run the following script.
For the very first time the SPI (contraray to the image) and I received the data on MISO and I ran the command multiple times to be sure. then I rebooted the jetson and ran the same script and SPI didnt work as can be seen in the pic above. The data I am sending on MOSI is not received on MISO.
Can you please guide me what I can check or what can go wrong after the boot.
For reference I am using jetpack 4.6.3 and jetson nano 4gb devkit. If someone need some other information I can provide that too.
Do you mean SPI could work as expected before reboot?
Could you provide the result of the following commands on your board for further check?
$ sudo cat /sys/kernel/debug/tegra_pinctrl_reg | grep -i spi
$ sudo cat /sys/kernel/debug/tegra_gpio
Yes it did work for the first time and then I rebooted the system and it stopped working. This happened to me on another jetson nano too that I had. Exact same thing.
Here are the outputs of the commands:
So I did some more testing today. I borrowed a jetson from a colleague I inserted the card in it and spi worked. I took ss of the files that you asked for.
when spi worked.txt (332.1 KB)
DTS of /proc/devcie-tree when sp worked
then I just rebooted the system and took the ss. There is difference in outputs of pin ctrls and gpio files. (they are more like the ones I provided earlier)
spi not working dts.txt (332.2 KB)
DTSof /proc/device-tree after reboot
Things are changein both files too
Now the “new” (that I borrowed) has stopped working.
It seems you only configure the pinmux for SPI1.
Could you refer to the following thread about verification for SPI loopback test on Jetson Nano?
Jetson Nano SPI Bus Not Working - #10 by KevinFFF
As per my reply above yours it worked for the first time when boot from the card and then after reboot the pin configurations changed as can be seen in pictures above. What is the reason for that? like If I follow the process that you have refered to check loop back test. thats almost doing the same thing that I did using the menu config and setting the SPI to as component instead of module that has to be modprobe. or isn’t it?
Yes I only need SPI1 at the moment, I dont need SPI2. Do I need to modify pinmux for both the SPIs to make it work?
I will do the test and get back to you.
Few questions regarding the approach in the loopback test to follow.
1- If I follow the method 2 for GPIO useage change , do I need to exactly replace the
(configuration in my tegra210-p3448-0000-p3449-0000-b00.dtb)
for my jetson nano 4gb devkit?
2- I am not flashing the jetson nano but making an sd card image and burning that image using Balenatcher and putting the SD card into the devkit. Does this work with this approach or I need to flash the Jetson nano?
3- What should be the output of /sys/kernel/debug/tergra_gpio ?
@KevinFFF Sorry for disturbing but I need to resolve it as soon as possible.
I did everthing starting from scratch as explained in
and the spi test still failed.
I am also selecting the GPIO based arbritaion option for i2c from menu config. Can it effect the SPI?
This modification would remove the GPIO usage for both SPI1 and SPI2.
I would suggest using SDKM to flash the devkit.
The first 2 bytes for B and C should be 0.
That is the workflow for SPI loopback test has been verified from us on the devkit.
Since you are using the devkit as ours so that I would suggest you follow that step-by-step.
I have no idea why you could only work at the “first” time.
Does the pinmux change or any errors showed in dmesg?
So I solved the issue after going through your recommendation of loopback test and reading some other posts on the forum. I am attaching the console logs when It works for the first time and when it doesn’t work after restart. The thing I noticed from that was the bootloader version was changing after the restart and then it kept the same for all the subsequent reboot/poweroffs. I read in some post on forum the similar case with someone else when they upgraded their jetpack version and using apt-get update and upgrade and someone there mentioned that the upgrade should be done using the SDK manager, not the apt-get update upgrade method. That gave me a kind of hint that the update of the bootloader version after reboot is breaking the SPI. So I plugged my Jetson devkit into the system and flashed it using the SDK manager keeping the configurations that you advised and it worked.
For reference I used Jetpack 4.6.3 and R32.7.3
new try.txt is when it worked and poweroff and reboot.txt are when it doesnot work.
Thanks for your help
reboot.txt (22.7 KB)
new try.txt (82.4 KB)
poweroff.txt (22.1 KB)
apt upgrade is not supported for Jetson device with L4T.
If you want to update a Jetson device, please refer to the following instruction.
Updating from the NVIDIA APT Server
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.