How to set to spi slave mode

Hello

I want to run spi test and connect through spi1 as the slave and spi3 as the master.My jetson xavier nx board has R35.6.1 installed.I referred to the following article:

I have done something as follow:

1.I modified the device tree and configured spi1 as slave mode

2.I ran Jetson-IO and selected spi1 and spi3 as follows:

3.I connected the following pins externally:

spi1_SCK<-> spi3_SCK spi1_din<-> spi3_dout spi1_dout<-> spi3_din spi1_cs0<-> spi3_cs0 spi1_cs1<-> spi3_cs1

4.I used devmem2 to write pinmux setting for spi1 and spi3 as follows:

spi1
pinmux.0x0243d008 = 0x00000450;
pinmux.0x0243d010 = 0x00000400;
pinmux.0x0243d018 = 0x00000400;
pinmux.0x0243d020 = 0x00000450;
pinmux.0x0243d028 = 0x00000400;

spi3
pinmux.0x0243d040 = 0x00000400;
pinmux.0x0243d048 = 0x00000400;
pinmux.0x0243d050 = 0x00000400;
pinmux.0x0243d058 = 0x00000400;
pinmux.0x0243d060 = 0x00000400;

5.I used commands as follows:

sudo ./spidev_test -D /dev/spidev2.0 -s8000000 -g512 -b32 -H -p0 -n1 -r &
sleep 5
sudo ./spidev_test -D /dev/spidev0.0 -s8000000 -g512 -b32 -H -p0 -n1 -zzz -t

The current result is as follows:

It seems that there are some wrong with spi1, what should I do?

Thank you!

Hi FuC,

Are you using the devkit or custom board for Xavier NX?
What’s the Jetpack version in use?

I suppose spidev0.0 is for SPI1_CS0 and spidev2.0 is for SPI3_CS0.
You might need to update spidev_test tool to keep slave in waiting state to receive the data.

Please also share the full dmesg and device tree for further check.

Hi KevinFFF,

I’m using devkit for Xavier NX.

Jetpack version is 5.1.4.

I want to know how to update spidev_test tool to keep slave in waiting state to receive the data.Could you tell me?

The dmesg and device tree as follows:

root@ubuntu:/home/nx/Downloads/spidev# dmesg | grep spi
[    2.572859] spi-tegra124-slave 3210000.spi: Adding to iommu group 0
[    2.577094] spi-tegra124-slave 3210000.spi: Reset control is not found
[    9.941565] spi-tegra114 3230000.spi: Adding to iommu group 0
[  284.915751] spi-tegra124-slave 3210000.spi: waiting for controller was interrupted
[  284.916400] spi_master spi0: failed to transfer one message from queue
[  506.392650] spi-tegra124-slave 3210000.spi: Not able to get desc for Tx
[  506.392961] spi-tegra124-slave 3210000.spi: Starting tx dma failed, err -5
[  506.393109] spi-tegra124-slave 3210000.spi: spi can not start transfer, err -5
[  506.393302] spi_master spi0: failed to transfer one message from queue
[  702.442679] spi-tegra124-slave 3210000.spi: Not able to get desc for Tx
[  702.442885] spi-tegra124-slave 3210000.spi: Starting tx dma failed, err -5
[  702.443082] spi-tegra124-slave 3210000.spi: spi can not start transfer, err -5
[  702.443271] spi_master spi0: failed to transfer one message from queue

device_tree.txt (393.7 KB)

Thank you very much.

Best wishes!

From the dmesg you shared, spidev0.0 is for Slave(3210000.spi), and spidev2.0 is for Master(3230000.spi) since SPI1 is probed earlier than SPI3.

Is there the -r and -t option for your spidev_test tool?
You can also simply write a script to run spidev_test in the loop.

1.Yes, I use spidev0.0 for slave and spidev2.0 for master.

2.There is some information for my spidev_test.

Usage: ./spidev_test [options]
 version 21
  -D --device   device to use (default /dev/spidev0.0)
  -s --speed    max speed (Hz)
  -g --length   transaction length in bytes. Multiple lengths can be comma separated.
  -z --debug    enable debug mode. Specifying more than once to increase the verboisty.
  -p --pattern  choose pattern type. Available patterns are:
                0: sequential bytes
                1: even bytes
                2: odd bytes
                3: reverse sequential bytes
                4: random bytes with crc
  -F prefix     Dump rx/tx buffer as raw to file. With no prefix specified, current pid will be used
  -f --file     Pattern file. User defined pattern. Not allowed with -p option.
                Pattern file must be in space seperated bytes in hex without
                "0x" prefix. Sample data: 01 AA 23 5F 3C 12
  -d --delay    delay (usec). For SPI master this will be the minimum delay 
                the driver waits before initiating each transfer. For slave
                this indicates the max delay that the slave waits before it times out.
  -E --expect   Expected transaction length in bytes.
                To test variable length data transfer feature.
                Without this option, spidev_test will assume it as normal transfer
                and will validate the actual transferred length with requested transaction length.
                Value should be less than or equal to the transaction length.
  -b --bpw      bits per word 
  -H --cpha     clock phase
  -O --cpol     clock polarity
  -L --lsb      least significant bit first
  -C --cs-high  chip select active high
  -n --nruns    Number of times to repeat the test. -1 is infinite.
  -u --udelay   delay b/w initiating each transfer (usec). Multiple delays can be comma separated
  -r --receive  only receive data
  -t --transmit only transmit data
  -v --minsize  variable length packet start
  -V --maxsize  variable length packet end
  -W --waitb4   wait for a keystroke before the first transfer
  -w --stoperr  stop on all errors
  -P --packet   packet mode

Examples:
To transfer 100 messages of 30 bytes each with random bytes,
  spidev_test -D/dev/spidev0.0 -s18000000 -n100 -g30 -p4

To transfer 100 messages of sizes 8 and 3986 with delay of 2ms and 8ms respectively,
  spidev_test -D/dev/spidev0.0 -s18000000 -n100 -g8,3968 -u2000,8000

To transfer all bytes from user defined pattern file,
  spidev_test -D/dev/spidev0.0 -s18000000 -f/path/to/patternfile

To test variable length feature,
  spidev_test -D/dev/spidev0.0 -s18000000 -g 30 -E 20

Return codes:
 0   successfull transfer. This would mean that what was
     transferred was actually received. Note that a success
     would make sense only when the spi is run in a loopback
     type configuration, i.e., a miso-mosi loopback or a
     master-slave loopback
 1   Invalid argument
 5   I/O error
 6   Data mismatch error. The transfer happened but there is 
     mismatch in tx and rx pattern. Again this makes sense only
     for loopback as explained above
 22  Invalid argument

3.I write a script and the results are:

transfer ioctl error: -1
/dev/spidev0.0: TEST FAILED !!!!! (status:-1)

What should I do?

@KevinFFF Hi, can you give me some advice?

It seems -t and -r option is available for your spidev_test tool.

You can simply run the following commands to verify.

$ echo 55 55 55 55 55 55 55 55 > pattern8.txt
$ sudo ./spidev_test -D /dev/spidev0.0 -s8000000 -g8 -b8 -H -f pattern8.txt -n1 -zzz -r
$ sudo ./spidev_test -D /dev/spidev2.0 -s8000000 -g8 -b8 -H -f pattern8.txt -n1 -zzz -t

Because it seems never to finish, I use ctrl+z to stop it, the result is :

root@ubuntu:/home/nx/Downloads/spidev# echo 55 55 55 55 55 55 55 55 > pattern8.txt
root@ubuntu:/home/nx/Downloads/spidev# sudo ./spidev_test -D /dev/spidev0.0 -s8000000 -g8 -b8 -H -f pattern8.txt -n1 -zzz 
using device: /dev/spidev0.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:0x68d344db
loop count = 0 
Using user defined pattern from pattern8.txt file ....
transfer bytes [8]
0000: 55 55 55 55 55 55 55 55 
^Ztransfer ioctl error: -1
/dev/spidev0.0: TEST FAILED !!!!! (status:-1)
====== Transfer stats ====
Transmit:
       total: 18446744073709551615B (18014398509481983KiB 17592186044415MiB)
       total: 1P 
       ioerr: 8B (0KiB 0MiB)
       ioerr: 1P
 Rate:
  wire total: 1659125143B/s (1620239KB/s)
       total: 1657336745B/s (1618492KB/s)
  wire total: 0P/s
       total: 0P/s
Receive:
       total: 0B (0KiB 0MiB)
       total: 0P 
        good: 0B (0KiB 0MiB)
        good: 0P
       ioerr: 1P
     dataerr: 0P
 Rate:
        good: 0B/s (0KB/s)
        good: 0P/s
 packet drop: -1/10000

  Total time: 52.772933s


You have to run the first command in first terminal, it will keep in waiting state to receive the data sent from master.
Then, you should run the second command in another terminal to send the data.

I run them as you tell me,the result of spi seems incorrect.

From the screenshot you shared, it seems the data has been sent correctly but the slave received all 0xFF.
Could you get a scope to measure the data on MOSI to check if it keeps high during the data transaction?

Please also share the full dmesg and device tree for further check.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.