[Jetson Nano SPI Issue] TX Data Present, RX Always Zero – Post-Reflash Debugging Steps & Observations

Robotics & Edge Computing Jetson & Embedded Systems Jetson Nano
,
1

I am debugging SPI communication on a Jetson Nano running JetPack 4 with Ubuntu 18.04. To begin troubleshooting, I dumped the running device tree using dtc -I fs -O dts -o running.dts /proc/device-tree and reviewed the output to confirm that SPI nodes were correctly configured. The SPI interfaces appeared as expected. Next, I verified the SPI pinmux configuration with sudo cat /sys/kernel/debug/tegra_pinctrl_reg | grep -i spi to ensure that the correct pins were assigned for SPI rather than GPIO. I also manually enabled SPI using the Jetson-IO tool and confirmed that SPI1 was properly assigned to the intended pins. After setting up SPI, I loaded the spidev module with sudo modprobe spidev and checked for available SPI devices by running ls /dev/spidev*. The output listed /dev/spidev0.0, /dev/spidev0.1, /dev/spidev1.0, and /dev/spidev1.1, confirming that the devices were recognized. I proceeded with an SPI loopback test running sudo ./spidev_test -D /dev/spidev0.0 -v and sudo ./spidev_test -D /dev/spidev1.0 -v showed that TX data was being sent, but the RX buffer consistently returned all zeros. I attempted to adjust SPI speed and switch between /dev/spidev1.0 and /dev/spidev1.1, but the issue remained unresolved. To rule out kernel-related issues, I checked dmesg | grep -i spi for any errors. The logs showed no critical errors. Suspecting that the SPI pins might still be assigned as GPIO by default, I ran sudo cat /sys/kernel/debug/tegra_pinctrl_reg | grep -i spi again to confirm that the correct pins were mapped for SPI functionality. Everything seemed in order.

To ensure that the issue was not caused by faulty wiring, i verified the continuity using a multimeter. The multimeter confirmed that the connection was sound, ruling out electrical wiring issues. Despite this, the loopback test continued to return TX data without any RX response.

Given this, I suspect one of the following possibilities: (1) the Jetson Nano might require explicit Chip Select (CS) control for proper loopback, meaning the CS line must be actively driven LOW during transmission; (2) the SPI controller might not support loopback mode without an actual slave device, which raises the question of whether there is an alternative way to validate loopback functionality

though, i am not totally sure if i am in the right direction as I am very new to the environment. i have tried direct nrf24 and jetson nano communication and it also did not communicate properly. what could i be doing wrong?

3

Hi normanwtsn,

Are you using the devkit or custom board for Jetson Nano?
What’s the exact Jetpack version in use?

Please refer to Jetson Nano SPI Bus Not Working - #10 by KevinFFF to verify SPI loopback test on Jetson Nano.
In this test, you don’t need to connect CS pin.

Please share the result of $ sudo cat /sys/kernel/debug/tegra_gpio on your board for further check.

4

hello. I am using an Nvidia Jetson Nano Developer Kit (b01 ; 4gb ram).

running the following commands

cat /etc/nv_tegra_release
dpkg-query --show nvidia-l4t-core

gave me

R32 (release), REVISION: 7.1, GCID: 29818004, BOARD: t210ref, EABI: aarch64, DATE: Sat Feb 19 17:05:08 UTC 2022

core
nvidia-l4t-core 32.7.1-20220219090432

which i assume is Jetpack 4.6.1 because of the l4t core version.

this one i had trouble with. since I have my image flashed in an sd card, i did not have access to the dtsi file natively and I was genuinely confused if I should get it via git or whatnot, but i proceeded to do the second method instead.

gpio-input = <0x5 0xbc 0xbd 0xbe 0xc1 0xa9 0xca 0x3a 0x$

this was my gpio input from kernel_tegra210-p3448-0000-p3449-0000-b00.dtb (my source dtb)
i changed gpio input to this as per instructions.

gpio-input = <0xd8 0x26 0x95 0x5 0xbc 0xbd 0xbe 0xc1 0xc2 0xa8 0xc8 0xca 0x4d 0x4e 0x4c 0x4f 0x32 0x33 0x3a 0x3d 0x3e 0x41 0xe4>;

however, after reassembling the dts back to the dtb via dtc -I dts -O dtb -o tegra210-p3448-0000-p3449-0000-b00.dtb extracted.dts and rebooting, I wanted to triple check if i had indeed enabled spi1 from the jetson-io tool. however, it is now crashing immediately after i try to get in. essentially, after I typed my password, it will show the menu for a split second and pushes me back to the cli command interface

i reviewed the logs and this is what it printed to me
^[[?1049h^[[22;0;0t^[[1;24r^[(B^[[m^[[4l^[[?7h^[[?1l^[>Traceback (most recent c$
File “/usr/lib/python3.6/curses/init.py”, line 78, in wrapper
cbreak()
_curses.error: cbreak() returned ERR

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File “/opt/nvidia/jetson-io/jetson-io.py”, line 594, in
curses.wrapper(JetsonIO)
File “/usr/lib/python3.6/curses/init.py”, line 100, in wrapper
nocbreak()
_curses.error: nocbreak() returned ERR

I am considering another reflash, but I would hold reflashing if it is not necessary.

Name:Bank:Port CNF OE OUT IN INT_STA INT_ENB INT_LVL
A: 0:0 64 40 40 04 00 00 000000
B: 0:1 f0 00 00 00 00 00 000000
C: 0:2 1f 00 00 18 00 00 000000
D: 0:3 00 00 00 00 00 00 000000
E: 1:0 40 00 00 00 00 00 000000
F: 1:1 00 00 00 00 00 00 000000
G: 1:2 0c 00 00 00 00 00 000000
H: 1:3 fd 99 00 60 00 00 000000
I: 2:0 07 07 03 02 00 00 000000
J: 2:1 f0 00 00 00 00 00 000000
K: 2:2 00 00 00 00 00 00 000000
L: 2:3 00 00 00 00 00 00 000000
M: 3:0 00 00 00 00 00 00 000000
N: 3:1 00 00 00 00 00 00 000000
O: 3:2 00 00 00 00 00 00 000000
P: 3:3 00 00 00 00 00 00 000000
Q: 4:0 00 00 00 00 00 00 000000
R: 4:1 00 00 00 00 00 00 000000
S: 4:2 a0 80 00 00 00 00 000000
T: 4:3 01 01 00 00 00 00 000000
U: 5:0 00 00 00 00 00 00 000000
V: 5:1 01 00 00 00 00 00 000000
W: 5:2 00 00 00 00 00 00 000000
X: 5:3 78 08 08 70 00 60 606000
Y: 6:0 06 00 00 02 00 00 000000
Z: 6:1 0f 08 08 04 00 06 020600
AA: 6:2 00 00 00 00 00 00 000000
BB: 6:3 01 00 00 00 00 00 000000
CC: 7:0 92 80 80 00 00 12 121200
DD: 7:1 01 00 00 00 00 00 000000
EE: 7:2 00 00 00 00 00 00 000000
FF: 7:3 00 00 00 00 00 00 000000

5

Update. I’ve pinpointed the problem and have done all the steps in

however, despite the efforts i did, this is what was printed.

spi mode: 0x0 bits per word: 8 max speed: 100000 Hz (100 KHz) TX | 48 65 6C 6C 6F 57 6F 72 6C 64 31 32 33 34 35 36 37 38 39 61 62 63 64 65 66 _ _ _ _ _ _ __ | HelloWorld123456789abcdef RX | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 _ _ _ _ _ _ __ | …

I verified if gpio was indeed disabled

sudo cat /sys/kernel/debug/tegra_pinctrl_reg | grep -i spi
Bank: 1 Reg: 0x70003050 Val: 0x0000e044 → spi1_mosi_pc0
Bank: 1 Reg: 0x70003054 Val: 0x0000e044 → spi1_miso_pc1
Bank: 1 Reg: 0x70003058 Val: 0x0000e044 → spi1_sck_pc2
Bank: 1 Reg: 0x7000305c Val: 0x0000e048 → spi1_cs0_pc3
Bank: 1 Reg: 0x70003060 Val: 0x0000e048 → spi1_cs1_pc4
Bank: 1 Reg: 0x70003064 Val: 0x00006046 → spi2_mosi_pb4
Bank: 1 Reg: 0x70003068 Val: 0x00006046 → spi2_miso_pb5
Bank: 1 Reg: 0x7000306c Val: 0x00006046 → spi2_sck_pb6
Bank: 1 Reg: 0x70003070 Val: 0x00006046 → spi2_cs0_pb7
Bank: 1 Reg: 0x70003074 Val: 0x00006045 → spi2_cs1_pdd0
Bank: 1 Reg: 0x70003078 Val: 0x0000e015 → spi4_mosi_pc7
Bank: 1 Reg: 0x7000307c Val: 0x0000e015 → spi4_miso_pd0
Bank: 1 Reg: 0x70003080 Val: 0x0000e015 → spi4_sck_pc5
Bank: 1 Reg: 0x70003084 Val: 0x0000e015 → spi4_cs0_pc6
Bank: 1 Reg: 0x70003088 Val: 0x00002040 → qspi_sck_pee0
Bank: 1 Reg: 0x7000308c Val: 0x00002000 → qspi_cs_n_pee1
Bank: 1 Reg: 0x70003090 Val: 0x00002040 → qspi_io0_pee2
Bank: 1 Reg: 0x70003094 Val: 0x00002040 → qspi_io1_pee3
Bank: 1 Reg: 0x70003098 Val: 0x00002040 → qspi_io2_pee4
Bank: 1 Reg: 0x7000309c Val: 0x00002040 → qspi_io3_pee5
Bank: 0 Reg: 0x70000b70 Val: 0x00000001 → drive_qspi_comp_control
Bank: 0 Reg: 0x70000b78 Val: 0x00000001 → drive_qspi_lpbk_control
Bank: 0 Reg: 0x70000a78 Val: 0x00808000 → drive_qspi_comp

and it indeed seems like it is

6

First, I would suggest you updating to the latest Jetpack 4.6.6(L4T R32.7.6) to verify.

Please run Jetson-IO tool first to configure the pinmux for SPI pins first because it would also generate a new entry in extlinux.conf and you should modify the new generated dtb ending with -custom.dtb

It seems some of your pins are still used for GPIO rather than SPI.
As my experience, they should be all zeros here.

Your pinmux configurations are correct for SPI.

7

thank you for this suggestion! I tried transitioning to this and these were the steps i did:

  1. I went to the site and downloaded the BSP and sample root filesystem on my laptop
  2. extracted bsp (tar xpf Jetson-210_Linux_R32.7.6_aarch64.tbz2)
  3. extracted the root file system (sudo tar xpf ~/jetson_nano_image/Tegra_Linux_Sample-Root-Filesystem_R32.7.6_aarch64.tbz2)
  4. applied binaries (sudo ./apply_binaries.sh)
  5. made the .img file (sudo ./create-jetson-nano-sd-card-image.sh -o sdcard.img -s 16G)

after flashing it onto my sd card and setting my jetson nano up, I double checked the version

dpkg-query --show nvidia-l4t-core
nvidia-l4t-core 32.7.6-20241104234540

outputs confirm that my Nano is running L4T version 32.7.6, which corresponds to JetPack 4.6.6
I immediately checked spi1 on the jetson-io tool and proceeded redoing Jetson Nano SPI Bus Not Working - #10 by KevinFFF

however, after completing it, im still met with zeroes when testing the spi

tried recompiling dts to see if the gpio input has the updated line but it seems as if it did not apply the changes. what i did was i re edited it again and extracted the dtb on somewhere i can transfer it to my laptop

  1. I did the same extraction of bsp and sample root file, and applying binaries
  2. tried replacing the dtb with my custom dtb (sudo cp /path to my custom/kernel_tegra210-p3448-0000-p3449-0000-b00-custom.dtb ~/jetson_nano_image/Linux_for_Tegra/rootfs/boot/dtb/kernel_tegra210-p3448-0000-p3449-0000-b00.dtb )
  3. flashed and set up

after this time, i immediately checked if the gpio was updated and to no avail :/ i cannot pinpoint why my dtb is not updating. I’ve tried locally setting a new dtb (first attempt above) and manually editing the dtb from the img file before the flash (second attempt)

though, I suspect that my dtb changes might be getting overwritten by the build script when I’m booting the nano for the first time; but this is just a hunch.

8

update. trying to fix the overwriting issue.

I found out in the medium article that the existence of extlinux.conf is not found in the sample root file system and that I should manually create one when making the image, which I did. After flashing I noticed that both dtb and extlinux were overwritten. This was the time I concluded that the nano is rewriting the changes i did. After rewriting the extlinux and adding FDT, i proceeded with re-editing the current dtb.

starting with the gpio input, I then adjusted the pinmux settings under pinmux@700008d4 to explicitly map spi1_mosi_pc0, spi1_miso_pc1, spi1_sck_pc2, and spi1_cs0_pc3 to the SPI function instead of their previous reserved state (rsvd1). afterward, I made it such that the dtb will not be overwritten by the system (sudo chattr +i /boot/dtb/kernel_tegra210-p3448-0000-p3449-0000-b00.dtb)

so far, it was good! the changes were applied and the dtb was not overwritten, however, it yielded no result when testing the spi communication. specifically, I still cannot receive any bits sent by the TX on my RX. I also noticed that

sudo cat /sys/kernel/debug/tegra_gpio

yielded the same result despite me having an edited dtb
what am I doing wrong?

9

Do you have an Ubuntu host to use flash command to flash your devkit directly?

This dtb will be overwritten by the one under <Linux_for_Tegra>/kernel/dtb/tegra210-p3448-0000-p3449-0000-b00.dtb during flash.

Do you use flash.sh to flash the devkit here?

Do you mean that there’s no /boot/extlinux/extlinux.conf on your board?

10

Do you have an Ubuntu host to use flash command to flash your devkit directly?

yes, I used a host running on Ubuntu 20.04.6 LTS

Do you use flash.sh to flash the devkit here?

I used Balena Etcher for this since my nano is running under sd card for its image. Essentially, the output of this is a .img file and I used that as a base to flash my sd card.

Do you mean that there’s no /boot/extlinux/extlinux.conf on your board?

yes, when I am making the .img from scratch using the resources from the nvidia l4t R32.7.6

11

It is not the expected result to me.

Could you just try using flash script to flash your devkit with SD inserted to prevent something missing?

12

sorry, have I been overcomplicating the flashing process? can you please guide me how to use the flash script with an sd card? I honestly thought using flash scripts are only for EMMC

13

Are you using Jetson Nano with eMMC or SD module?

If you are using Jetson Nano with SD module(i.e. SD card is inserted on the module), please simply run the following command to flash the devkit.

$ cd <Linux_for_Tegra>/
$ sudo ./flash.sh jetson-nano-devkit mmcblk0p1
14

Hello again @KevinFFF, yes I am using Jetson Nano with SD module.

I’ve managed to study VirtualBox so that i can locally use the flash script without having to etch an image onto the sd card via balena etcher.

from here, I went ahead and redid these steps

  1. I went to the site and downloaded the BSP and sample root filesystem on my laptop
  2. extracted bsp (tar xpf Jetson-210_Linux_R32.7.6_aarch64.tbz2)
  3. extracted the root file system (sudo tar xpf ~/jetson_nano_image/Tegra_Linux_Sample-Root-Filesystem_R32.7.6_aarch64.tbz2)

which enables me to follow the steps again in

Jetson Nano SPI Bus Not Working - #10 by KevinFFF

specifically,

Check flash log to know which dtb you are using (in my case, is the a00
Method 2 - Remove from decompiled dtb
2-2-2-1 Find you dtb in Linux_for_Tegra/kernel/dtb/tegra210-p3448-0000-p3449-0000-a00.dtb

2-2-2-2 Dissemble the dtb to dts
dtc -I dtb -O dts -o temp.dts tegra210-p3448-0000-p3449-0000-a00.dtb

2-2-2-3 Modify the following line

  •    gpio-input = <0xd8 0xc 0xd 0xe 0xf 0xe8 0x26 0x95 0x5 0xbc 0xbd 0xbe 0xc1 0xc2 0xa8 0xc8 0xca 0x4d 0x4e 0x4c 0x4f 0x32 0x33 0x10 0x11 0x12 0x13 0x14 0x3a 0x3d 0x3e 0x41 0xe4>;

  •    gpio-input = <0xd8 0x26 0x95 0x5 0xbc 0xbd 0xbe 0xc1 0xc2 0xa8 0xc8 0xca 0x4d 0x4e 0x4c 0x4f 0x32 0x33 0x3a 0x3d 0x3e 0x41 0xe4>;

2-2-2-4 Assemble the dts back to dtb
dtc -I dts -O dtb -o tegra210-p3448-0000-p3449-0000-b00.dtb temp.dts

2-2-2-5 Flash the board

In the flashing process, I followed this forum’s (How to Put NVIDIA Jetson NANO B01 in Force Recovery Mode? - #2 by andres.campos) instruction for putting the nano into force recovery mode

So, I tried flashing and I was stuck in the line

[   0.0826 ] Boot Rom communication
[   0.1065 ] tegrarcm --chip 0x21 0 --rcm rcm_list_signed.xml --skipuid

I did verify that VirtualBox connected to my nano and I double checked using $ lsusb which printed

Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 003: ID 80ee:0021 VirtualBox USB Tablet
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 0955:7f21 NVIDIA Corp. APX

despite proving connection by the software and the cli, i seem to get stuck in that line when flashing.

15

We would suggest using standalone Ubuntu host PC rather than VM/docker/WSL2 since the Jetson device would reboot few times during flashing and the connection between Jetson and PC would be unstable.