But I only changed SPI2 to slave mode, so I only tested SPI2.
Do you mean I should set all SPI interfaces to slave mode and test this command one by one?
I cannot reproduce the similar issue on the devkit.
I just update the following line in device tree.
spi@c6c0000 {
- compatible = "nvidia,tegra234-spi\0nvidia,tegra210-spi";
+ compatible = "nvidia,tegra210-spi-slave";
status = "okay";
#address-cells = <0x01>;
#size-cells = <0x00>;
reg = <0x00 0xc6c0000 0x00 0x10000>;
..
In dmesg:
$ sudo dmesg|grep spi
[ 11.938034] spi-tegra114 810c590000.spi: Adding to iommu group 29
[ 11.996687] spi-tegra114 810c440000.spi: Adding to iommu group 31
[ 12.013271] spi-tegra114 810c450000.spi: Adding to iommu group 32
[ 12.183266] spi-tegra124-slave c6c0000.spi: Adding to iommu group 33
After running spidev_test for SPI2(c6c0000.spi) with -r option, it will stay in the following state instead of returning FAILED immediately.
$ 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:0x6a01426f
loop count = 0
Oh, I’ve already modified and verified this part, but the result is still the same.
I roughly understand what you mean.
If I just run the command alone, it won’t return FAILED immediately. But since I have another SPI configured in master mode connected directly to it to send data, while SPI2 is set for reception, it returns FAILED immediately.
If the other SPI doesn’t send any data, it won’t report FAILED immediately.
What I meant earlier is that as soon as the other SPI starts sending data, SPI2 immediately returns FAILED.
Sorry I didn’t explain this clearly earlier.
Thanks for your clarification.
It seems the FAILED reported as you have connected SPI2 with another SPI master(SPI3).
I think the issue may be caused from that the level is different between SPI2 and SPI3.
SPI2 may be 1V8 while SPI3 may be 3V3.
Could you check this by measuring their signal respectively?
I’ve confirmed with the hardware engineer that both SPI interfaces on our mainboard pass through level-shifting chips and are currently set to 3.3V.
Could I ask if you have ever tested configuring two different SPI interfaces on the Thor DevKit, with one set as Master and the other as Slave, for intercommunication verification?
I’m urgently trying to resolve this issue, and would really appreciate it if you could help perform this validation test for me.
There’s no expansion header on the devkit to do this task, so it may take more time for me to verify this locally.
In the meantime, could you check if the issue is specific to the SPI2?
(i.e. you can configure SPI1 as slave and SPI3 as master)
Could you share the connections of the level shifter in your case?
Alright, fully understood.
Sure, I’ll give it a try and get back to you with the test results.
No problem. I’ll check with the hardware engineer and provide all the information together.
Could you also share how do you connect to perform transaction between SPI2 and SPI3?
Do you connect them as following?
AURIX_SPI_MOSI <----> AURIX_SPI3_MOSI
AURIX_SPI_MISO <----> AURIX_SPI3_MISO
AURIX_SPI_SCK <----> AURIX_SPI3_SCK
AURIX_SPI_CS <----> AURIX_SPI3_CS_N
If so, can you remove the level shifter and measure the level of SOC_SPI2_MOSI and SOC_SPI3_MOSI during boot up?
The wiring connection is correct.
Unfortunately, our chip is placed underneath the Thor module, so we can’t measure the voltage even after trying.
Our hardware engineer confirms the voltage should be fine, and the circuit was designed strictly following the reference design. We’d like to know why you need to verify the voltage at this part.
Are there any other points we can check?
Hello. We soldered out wires for measurement, and during the boot up process, the voltage of SOC_SPI2_MOSI and SOC_SPI3_MOSI are both 0V.
Hello.，
We still encounter issues no matter how we adjust the configuration.
I checked the official guide document, but it only covers AGX Orin and Orin NANO. Could you please share if there is a corresponding document specifically for Thor?
Please run the following command and check from scope. (confirm SOC_SPI2_MOSI and SOC_SPI3_MOSI do not connect each other)
sudo ./spidev_test -D /dev/spidev0.0 -v -p "HelloWorld123456789abcdef"
Since the Thor platform does not support SPE, there is no corresponding documentation available.
Thanks for measuring the signal.
Are they 1V8 or 2V0?
Have you tried simply shorting SOC_SPI2_MOSI and SOC_SPI3_MOSI at this moment?
You can also do the same task for AURIX_SPI_MOSI and AURIX_SPI3_MOSI(i.e. after the level shifter) w/o external loopback.
In addition, there’s another SPI CS related issue which has been identified in JP7.1(r38.4).
Could you apply the patch from the following thread to check if it could help for your case?
[T5000] SPI3 connect to TPM fail - #41 by KevinFFF
They are 1V8.
Do you mean only connect SOC_SPI2_MOSI and SOC_SPI3_MOSI, and leave the other three pins unconnected?
Correct, short SOC_SPI2_MOSI and SOC_SPI3_MOSI w/o using level shifter.
OK, I just tried again. I only connected SOC_SPI2_MOSI and SOC_SPI3_MOSI, then ran the command:
sudo ./spidev_test -D /dev/spidev2.0 -v -p "HelloWorld123456789abcdef"
The waveforms on both sides are identical.
We’ve also tried this patch, but the result remains the same. SPI2 still cannot receive data when configured as Slave.
Is there any reference material available for this error? Could it be an issue with the FIFO?
[ 1001.906693] spi_master spi1: transferred[16] != requested[8]
[ 1001.906698] spi_master spi1: CMD[13f01027]: Sl M1 CS0 [HHHH] MSB MSb Rx Pa 8b TRANS[00ff0010]:BSY I:255 B:16
FIFO[02400004]:RxF:4 TxE:64 Err[] RxSTA[] TxSTA[E]DMA[00000000]: RxTr:0 TxTr:0 B:7
[ 1001.906709] spi_master spi1: cpu-xfer-err [status:02400004]
[ 1001.906709] spi_master spi1: CMD[13f01027]: Sl M1 CS0 [HHHH] MSB MSb Rx Pa 8b TRANS[00ff0010]:BSY I:255 B:16
FIFO[02400004]:RxF