SPI read imx93

[BaselHn]

Hi, 
I am interfacing TI TUSS7740 with the i.MX93 FRDM board, the TUSS communicates over SPI 
I connected the TUSS SPI to the imx93 LPSPI 3  according to the FRDM schematics:

The DTS node:

&lpspi3 {

fsl,spi-num-chipselects = <1>;

pinctrl-names = "default", "sleep";

pinctrl-0 = <&pinctrl_lpspi3>;

pinctrl-1 = <&pinctrl_lpspi3>;

cs-gpios = <&gpio2 8 GPIO_ACTIVE_LOW>;

dma-noncoherent;

pinctrl-assert-gpios = <&pcal6408 0 GPIO_ACTIVE_HIGH>;

status = "okay";

spidev0: spi@0 {

reg = <0>;

compatible = "lwn,bk4";

spi-max-frequency = <500000>;

spi-cpha; // This sets SPI mode 1 (CPOL=0, CPHA=1)

};

};

I run the test to read the TUSS chip ID :
spidev_test -D /dev/spidev0.0 -s 500000 -b 8 -H -p "\xBA\x00" -v

and I always read zeros :
root@imx93frdm:~# spidev_test -D /dev/spidev0.0 -s 500000 -b 8 -H -p "\xBA\x00" -v
spi mode: 0x1
bits per word: 8
max speed: 500000 Hz (500 kHz)
TX | BA 00 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ |..|
RX | 00 00 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ |..|

But in the logic analyzer, I see a correct communication :

What am I missing? 

BR
Basel

[pengyong_zhang · Accepted solution]

Hi @BaselHn 

Yes, you are right: pinctrl-assert-gpios = <&pcal6408 0 GPIO_ACTIVE_HIGH>; in DTS activates the SPI3 to Wi-Fi PHY level converter。

You can remove it from the dts file.

B.R

[pengyong_zhang]

hI @BaselHn 

You mean this level shifter? It seems from 3.3V to 1.8V, you disconnect the R2797 R2799 R2801 R2805, then resolve the problem?

B.R

[BaselHn]

Hi @pengyong_zhang 

Yes, I also disconnected R2810, R2813, R2815, and R2817. Then it solved the problem.
But when I took another look at the schematics, I think the problem lies in the DTS here :

&lpspi3 {

fsl,spi-num-chipselects = <1>;

pinctrl-names = "default", "sleep";

pinctrl-0 = <&pinctrl_lpspi3>;

pinctrl-1 = <&pinctrl_lpspi3>;

cs-gpios = <&gpio2 8 GPIO_ACTIVE_LOW>;

pinctrl-assert-gpios = <&pcal6408 0 GPIO_ACTIVE_HIGH>;

dma-noncoherent;

status = "okay";

spidev0: spi@0 {

reg = <0>;

compatible = "lwn,bk4";

spi-max-frequency = <8000000>;

spi-cpha;

};

};

I think that this line is the problem: pinctrl-assert-gpios = <&pcal6408 0 GPIO_ACTIVE_HIGH>;

It enables the level shifter according to the schematics:

The SPI3_SW_EN is connected to :

Which is defined in the DTS :).  I think the problem has stood since the Tuss tries to raise the line to 3.3 volts and the level shifter makes it 1.2 volts, because of the misconfiguration in the DTS, which enables the level shifter to the MAYA wi-fi PHY. 

Can you confirm this?

BR
Basel

[pengyong_zhang]

HI @BaselHn 

You need to run the tset code by yourself, make the spi deive send the data to your master, the you can see the data on the MISO.

You mentioned : I see the data with the logic analyzer, but I did not receive the data on the SOC side.

>>> Could you share your test method and the test result. Include the logic analyzer and log file

[BaselHn]

Hi
I managed to solve the problem, the imx93 frdm has a wifi module which is also connected to the same SPI with a level shifter, the level shifter cuase the MISO line to be always at 1.2 volt level, then the SPI always see's 0 logic on the line, once I disconnect the SPI from the level shifter, (removing the zero resistors) every thing works fine.

[BaselHn]

Hi @pengyong_zhang 

I tried to run the test from the terminal:
pidev_test -D /dev/spidev0.0 -s 500000 -b 8 -H -p "\xBA\x00" -v
spi mode: 0x1
bits per word: 8
max speed: 500000 Hz (500 kHz)
TX | BA 00 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ |..|
RX | 00 00 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ |..|

Also, I tried to run this C code :

#include <stdio.h>
#include <stdint.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <linux/spi/spidev.h>
#include <string.h>
#include <errno.h>

int main() {
int fd = open("/dev/spidev0.0", O_RDWR);
if (fd < 0) {
perror("open");
return 1;
}

uint8_t mode = SPI_MODE_1;
uint8_t bits = 8;
uint32_t speed = 500000;

if (ioctl(fd, SPI_IOC_WR_MODE, &mode) < 0 ||
ioctl(fd, SPI_IOC_WR_BITS_PER_WORD, &bits) < 0 ||
ioctl(fd, SPI_IOC_WR_MAX_SPEED_HZ, &speed) < 0) {
perror("SPI setup");
close(fd);
return 1;
}

uint8_t tx[2] = { 0xBA, 0x00 }; // Example: read reg 0x1D
uint8_t rx[2] = { 0 };

struct spi_ioc_transfer tr = {
.tx_buf = (__u64)(uintptr_t)tx,
.rx_buf = (__u64)(uintptr_t)rx,
.len = 2,
.speed_hz = speed,
.bits_per_word = bits,
.cs_change = 0,
};

int ret = ioctl(fd, SPI_IOC_MESSAGE(1), &tr);
if (ret < 1) {
perror("SPI_IOC_MESSAGE");
close(fd);
return 1;
}

printf("TX: 0x%02X 0x%02X\n", tx[0], tx[1]);
printf("RX: 0x%02X 0x%02X\n", rx[0], rx[1]);
printf("Received Device ID: 0x%02X\n", rx[1]);

close(fd);
return 0;
}

In both, I get the same result. In the following snapshot, you can see the logic analyzer:

[pengyong_zhang]

Hi @BaselHn 

Your spi configuration is right! You need to run the loopback test, then you can see the data on the RX.

B.R

[BaselHn]

Hi @pengyong_zhang 

I run the loopback test, and I see data on the MISO pin. The problem occurs when I connect the MISO and MOSI to the TUSS. I see the data with the logic analyzer, but I did not receive the data on the SOC side.

BR 
Basel