Hello!
I have a problem with the Kernel customization regarding SPI. The existing hardware connects a FRAM and a TPM module on one SPI, using CS0 and CS1. It is running fine with a Jetson Nano already, the problem with the Xavier NX module is a different behaviour of the hardware controlled chip select signal (CS0). The following description applies to the FRAM, the TPM is no problem is both configurations.
The SPI is controlled by the “ioctl” function, making use of the option “cs_change”. The FRAM needs the Opcode, the 24bit address followed by memory data. The CS must be held low from Opcode till the end of the data stream. Following code is running fine on the Nano:
uint8_t tx[4] = { OPCODE_WRITE };
tx[1] = (uint8_t) (address >> 16) & 0xFF;
tx[2] = (uint8_t) (address >> 8) & 0xFF;
tx[3] = (uint8_t) (address & 0xFF);
struct spi_ioc_transfer tr = { .tx_buf = (unsigned long) tx, .rx_buf = 0,
.len = 4, .delay_usecs = delay, .speed_hz = 0, .bits_per_word = 0,
.cs_change = 0, };
struct spi_ioc_transfer tr2 = { .tx_buf = (unsigned long) send, .rx_buf = 0,
.len = len, .delay_usecs = delay, .speed_hz = 0, .bits_per_word = 0,
.cs_change = 1, };
ret = ioctl(fd, SPI_IOC_MESSAGE(1), &tr);
if (ret < 0)
{
spi_fram_debug_out("can't send spi message");
}
ret = ioctl(fd, SPI_IOC_MESSAGE(1), &tr2);
The cs_change option works as expected on the Nano but not on the Xavier NX. I believe the problem arises from the setup in the DTS files. These are attached to this topic.
To illustrate the problem, this is the capture in the Nano setup:
and this is the Xavier setup:
The marked CS high happens between the 4 byte Opcode+address and the data section.
Any hints to the DTS configuration for this problem?
tegra194-p3668-nb_xav_nx.dts (246.2 KB)
tegra210-nb_nano.dts (326.2 KB)
