SPI2 cannot receive data when operating in slave mode

Robotics & Edge Computing Jetson Systems Jetson Thor
1

When both SPI2 and SPI3 are configured in Master mode, loopback test shows normal transmission and reception. However, when SPI2 is switched to Slave mode for cross-testing, SPI2 cannot receive any data at all.
Using R38.4.0.

Currently, the pinmux and device tree have been modified as follows:

spi@c6c0000 {
                        compatible = "nvidia,tegra210-spi-slave";
                        status = "okay";
                        #address-cells = <0x01>;
                        #size-cells = <0x00>;
                        reg = <0x00 0xc6c0000 0x00 0x10000>;
                        interrupts = <0x00 0x216 0x04>;
                        dma-coherent;
                        dma-names = "rx\0tx";
                        dmas = <0x133 0x08 0x08 0x808 0x133 0x08 0x12 0x808>;
                        iommus = <0x05 0x808>;
                        clocks = <0x02 0x2b 0x02 0xa0 0x02 0x01>;
                        clock-names = "spi";
                        assigned-clocks = <0x02 0x2b>;
                        assigned-clock-parents = <0x02 0xa0>;
                        resets = <0x02 0x25>;
                        reset-names = "spi";
                        spi-max-frequency = <0x2faf080>;
                        phandle = <0x28c>;

                        prod-settings {
                                #prod-cells = <0x04>;

                                prod {
                                        prod = <0x00 0x194 0x80000000 0x00>;
                                };
                        };


                        spi@0 {
                                compatible = "tegra-spidev";
                                reg = <0x00>;
                                spi-max-frequency = <0x2faf080>;
                                nvidia,enable-hw-based-cs;

                                controller-data {
                                        nvidia,enable-hw-based-cs;
                                        nvidia,rx-clk-tap-delay = <0x10>;
                                        nvidia,tx-clk-tap-delay = <0x0>;
                                };
                        };
                };

image
image418×828 16.8 KB

Tested with the tool from this link, no output is generated on the slave side at all.

image
image711×196 6.44 KB

image
image867×439 9.94 KB

Please help take a look at this issue, thank you!

3

Could you please take a look at this as soon as possible? We’re in urgent need of it.
Thanks.

4

Hi kepts,

Are you using the custom carrier board for Thor to verify SPI as there’s no expansion header on the AGX Thor devkit for this task?

What’s the Jetpack version in use?

Could you share the result of ls -l /dev/spi* for further check if /dev/spidev1.0 is actually the node for SPI2?

Based on the dmesg you shared, I think SPI2(c6c0000.spi) is enumerated as /dev/spidev3.0 due its order of probing.

5

We are using custom carrier board and JetPack‘s version is 7.1.
The spidev configuration should be correct.

image
image648×142 5 KB

image
image852×427 9.39 KB

6

Supplement the dmesg logs during sending and receiving.

image
image935×608 31.9 KB

7

Do you connect the MOSI and MISO for loopback testing?

8

We have performed loopback tests when both SPI2 and SPI3 are configured in Master mode.

9

So only the slave mode have problem for the loopback test?

10

Yes. When in Slave mode, it fails in both loopback tests and cross communication tests with other SPI controllers configured as Master mode.

11

Could you refer to the steps in https://elinux.org/Jetson/L4T/peripheral/#Slave_Mode to verify SPI slave?

It would expect that you run -r for the SPI slave before run -t for the SPI master.
You can also get a scope or LA to measure its signal.

12

I did follow this procedure for the test. I first opened one terminal to run the slave program, then opened another terminal to run the master program.

3. Run SPI slave
$ sudo ./spidev_test -D /dev/spidev1.0 -s8000000 -g8 -b8 -H -f pattern.txt -n1 -zzz -r

4. Run SPI master
$ sudo ./spidev_test -D /dev/spidev0.0 -s8000000 -g8 -b8 -H -f pattern.txt -n1 -zzz -t

During the test can be measured its signal on the MOSI, CLK and CS pins of the slave interface.

13

Do you mean the signal is expected(level and data) but the spidev_test tool still reports FAILED?

In addition, is the spidev_test for SPI slave reporting FAILED immediately? Or it stays in the state waiting to receive the data from SPI master?

14

Yes.

As shown in the figure, it keeps reporting FAILED repeatedly.

image
image852×427 9.39 KB

15

Please help to answer this.

I would expect spidev_test for SPI slave in the state waiting for the data rather than reporting FAILED immediately?

16

It’s basically getting a response immediately. On my side, the master keeps sending data continuously. I’m monitoring the slave side with watch -n 1, and it keeps showing failed every second nonstop; it’s not in a waiting state at all.

17

Based on my experience, it could happen in the SPI interface configured as SPI master rather than SPI slave.

Could you try using the following spidev_test tool which is built for Thor with JP7.1(r38.4)?
spidev_test (107.3 KB)

18

Okay, I’ll give it a try first.
By the way, is there anything wrong with my previous configuration for switching to slave mode?

19

The result appears to be the same.

image
image855×423 9.33 KB

image
image940×127 8.07 KB

20

Hi,
Is there anything wrong with my previous configuration for switching to slave mode?
Do you have any other suggestions? We really need your help urgently.

21

Could you run the same command for each SPI interface to check if each interfaces all return FAILED immediately?