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
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.
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
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)
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.
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.