We want to use SPI3 in slave mode. We’ve configured the connections according to this example( Making sure you're not a bot! ). However, we can’t receive data using spidev_test. The waveforms measured on the hardware are normal.
Here is the current dmesg and extracted_proc
dmesg.log (58.4 KB)
extracted_proc.txt (324.8 KB)
We also modified pinmux and dtbo according to this. The result is the same
Hi yuelingyan,
Are you using the devkit or custom board for Orin NX?
What’s the Jetpack version in use
[ 10.242074] spi-tegra124-slave 3230000.spi: Adding to iommu group 1
[ 10.242150] spi-tegra124-slave 3230000.spi: Dynamic bus number will be registered
[ 10.243275] spi-tegra114 3210000.spi: Adding to iommu group 1
From the dmesg you shared, it seems SPI1(as Master) and SPI3(as Slave) have been configured and probed correctly. SPI3 should be available with /dev/spidev0.0, and SPI1 should be available with /dev/spidev1.0
Could you share the steps how do you verify them? using spidev_test with -t(for SPI master) and -r(for SPI slave) respectively?
Please share the detailed commands you run.
We are using a custom Orin NX，and the Jetpack version is L4T 36.3 Jetpack 6.0.
This /dev/spidev0.0 may change every time I boot up. I use “ll /sys/class/spi_master/spi0/” to check which spi1 and spi3 correspond to.
Test steps：
1、connect: SPI1-CLK<–>SPI3-CLK, SPI1-CS<–>SPI3-CS, SPI1-MOSI<–>SPI3-MOSI, SPI1-MISO<–SPI3-MISO
2、Run Jetson IO
sudo /opt/nvidia/jetson-io/jetson-io.py
Configure Jetson 40pin Header => Configure header pins manually => Select “spi1 (19,21,23,24,26) spi3 (13,16,18,22,37)” => Back → Save pin changes => Save and reboot to reconfigure pins
3、Update device tree (/boot/dtb/kernel_tegra234-p3768-0000+p3767-0000-nv.dtb)
sudo dtc -I dtb -O dts /boot/dtb/kernel_tegra234-p3768-0000+p3767-0000-nv.dtb -o ./kernel_tegra234-p3768-0000+p3767-0000-nv.dts
compatible = “nvidia,tegra210-spi”; => compatible = “nvidia,tegra210-spi-slave”;
sudo dtc -I dts -O dtb ./kernel_tegra234-p3768-0000+p3767-0000-nv.dts -o /boot/dtb/kernel_tegra234-p3768-0000+p3767-0000-nv.dtb
4、reboot
5、echo 55 55 55 55 55 55 55 55 > pattern.txt
6、One terminal executes：
sudo ./spidev_test -D /dev/spidev0.0 -s8000000 -g8 -b8 -H -f pattern.txt -n1 -zzz -r
7、Another terminal executes：
sudo ./spidev_test -D /dev/spidev1.0 -s8000000 -g8 -b8 -H -f pattern.txt -n1 -zzz -t
It is expected as they are assigned dynamically according to the order of the probe.
I’m not sure if you have the similar design and usage on the 40-pins header as the devkit.
If not, jetson-io may not work on your custom carrier board. Please use pinmux spreadsheet to configure them instead.
Your test commands look good to me.
Please share the result when you run these 2 spidev_test commands.
The following are the execution results
sudo ./spidev_test -D /dev/spidev1.0 -s8000000 -g8 -b8 -H -f pattern.txt -n1 -zzz -r
Disabling transmit
using device: /dev/spidev1.0
setting spi mode for read,write
setting spi bpw
setting max speed for rd/wr
spi mode: 1
bits per word: 8 bytes per word: 1
max speed: 8000000 Hz (8000 KHz)
no. runs: 1
Using seed:0x68f725f6
loop count = 0
sudo ./spidev_test -D /dev/spidev0.0 -s8000000 -g8 -b8 -f pattern.txt -n1 -zzz -t
Disabling receive
using device: /dev/spidev0.0
setting spi mode for read,write
setting spi bpw
setting max speed for rd/wr
spi mode: 0
bits per word: 8 bytes per word: 1
max speed: 8000000 Hz (8000 KHz)
no. runs: 1
Using seed:0x68f725fe
loop count = 0
Using user defined pattern from pattern.txt file …
transfer bytes [8]
0000: 55 55 55 55 55 55 55 55
/dev/spidev0.0: TEST PASSED
====== Transfer stats ====
Transmit:
total: 8B (0KiB 0MiB)
total: 1P
ioerr: 0B (0KiB 0MiB)
ioerr: 0P
Rate:
wire total: -1B/s (0KB/s)
total: -1B/s (0KB/s)
wire total: -1P/s
total: -1P/s
Total time: 0.000281s
We also modified pinmux according to this( Enable SPI1 as Slave on Jetson Orin NX ). The result is the same
Could you get a scope to measure the signal on MOSI line when you send data from SPI master?
I used an oscilloscope to measure that data is being sent. There are signals on clk, cs, and mosi.
Is the slave side not receiving any data at that moment?
Does it stay in the state to wait the data to be received?
Yes. No data has been received and it stay in this state.
Do you have the Orin Nano devkit to reproduce the similar issue?
I have now switched to a Orin Nano devkit and the same problem still occurs using the previous test steps.
Hi Kevin
What else can I try?
It is weird that I’ve verified it working on the devkit.
Could you also try using the following spidev_test tool to verify?
spidev_test (103.4 KB)
I tried this as well, and it still works the same. Are our operations the same? And the Jetpack version is L4T 36.3 Jetpack 6.0.
It is the first JP6 release.
Could you also verify with the latest JP6.2.1(L4T r36.4.4)?
Is this still an issue to support? Any result can be shared