topic Re: SPI read imx93 in Other NXP Products

SPI read imx93

BaselHn — Mon, 07 Jul 2025 12:15:47 GMT

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

Re: SPI read imx93

pengyong_zhang — Tue, 08 Jul 2025 01:49:54 GMT

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

Re: SPI read imx93

BaselHn — Tue, 08 Jul 2025 06:40:41 GMT

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

Re: SPI read imx93

pengyong_zhang — Wed, 09 Jul 2025 02:38:38 GMT

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

Re: SPI read imx93

BaselHn — Wed, 09 Jul 2025 07:34:44 GMT

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:

BaselHn_0-1752046457136.png

Re: SPI read imx93

BaselHn — Wed, 09 Jul 2025 13:12:36 GMT

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.

Re: SPI read imx93

pengyong_zhang — Thu, 10 Jul 2025 02:25:46 GMT

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?

pengyong_zhang_0-1752114214556.png

B.R

Re: SPI read imx93

BaselHn — Thu, 10 Jul 2025 06:57:52 GMT

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:
BaselHn_0-1752130489667.png

The SPI3_SW_EN is connected to :

BaselHn_1-1752130540029.png

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

Re: SPI read imx93

pengyong_zhang — Fri, 11 Jul 2025 01:00:51 GMT

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