Early use of spi (spi@c260000) on AGX Industrial crashes

Hi.

In some ways a continuation of topic: Spi@c260000 on Jetson AGX Xavier Industrial

We got spi@c260000 working on the Jetson AGX Xavier Industrial on a custom board.

However, we are facing an issue we would like some assistance in:
If we use the spi/spidev early on after booting, it crashes the AGX. But, if we wait approx 1 min after the login prompt is shown in the debug-UART/-port - everything works fine/it seems rock solid.

Have tried flashing the unit with “-c ‘ignore_loglevel’” to get a more verbose output - but we cannot see any prints either “directly in the serial terminal” or in dmesg after the login prompt is shown. This gives us the impression that the boot is completed - but something is probably still being setup in the background(?).

How can we figure out what is going on, and how to know when the spi@c260000 is actually fully usable? Is this a known thing? Any help is appreciated.

Error that appears when the AGX crashes:

[ 65.923500] spi-tegra114 c260000.spi: CpuXfer ERROR bit set 0x400055
[ 65.924396] spi-tegra114 c260000.spi: CpuXfer 0x43c01827:0x00000000
[ 65.925760] spi-tegra114 c260000.spi: SPI_ERR: CMD_0: 0x43d08000, FIFO_STS: 0x01c00054
[ 65.930173] spi-tegra114 c260000.spi: SPI_ERR: DMA_CTL: 0x00000000, TRANS_STS: 0x40ff000b
[ 65.923500] spi-tegra114 c260000.spi: CpuXfer ERROR bit set 0x400055
[ 65.924396] spi-tegra114 c260000.spi: CpuXfer 0x43c01827:0x00000000
[ 65.925760] spi-tegra114 c260000.spi: SPI_ERR: CMD_0: 0x43d08000, FIFO_STS: 0x01c00054
[ 65.930173] spi-tegra114 c260000.spi: SPI_ERR: DMA_CTL: 0x00000000, TRANS_STS: 0x40ff000b
[ 76.140985] spi-tegra114 c260000.spi: spi transfer timeout
[ 76.145769] spi-tegra114 c260000.spi: SPI_ERR: CMD_0: 0x43d00000, FIFO_STS: 0x00400005
[ 76.140985] spi-tegra114 c260000.spi: spi transfer timeout
[ 76.145769] spi-tegra114 c260000.spi: SPI_ERR: CMD_0: 0x43d00000, FIFO_STS: 0x00400005
[ 76.152888] spi-tegra114 c260000.spi: SPI_ERR: DMA_CTL: 0x00000000, TRANS_STS: 0x00ff0000
[ 76.155372] spi_master spi1: failed to transfer one message from queue
[ 76.152888] spi-tegra114 c260000.spi: SPI_ERR: DMA_CTL: 0x00000000, TRANS_STS: 0x00ff0000
[ 76.155372] spi_master spi1: failed to transfer one message from queue

and sometimes:

[ 74.082031] spi-tegra114 c260000.spi??--------------------------------------------------------------------------------
Exception: Data abort
DFAR: 0x0c0f0008, DFSR: 0x00001008
PC: 0x0c480b10
LR: 0x0c480987, SP: 0x0c49cce0, PSR: 0x4000003f
R0: 0x00000001, R1: 0x0c49cd62, R2: 0x00000000
R3: 0x0c0f0000, R4: 0xfffffffe, R5: 0x00000000
R6: 0x00000002, R7: 0x0c494bd4, R8: 0x0c49cd62
R9: 0x0c49cd60, R10: 0xffffffff, R11: 0x00000000
R12: 0x00000000

dtsi looks like:

/* spi1 */
spi@c260000 {
status = “okay”;
spi@0 {
compatible = “tegra-spidev”;
reg = <0x0>;
spi-max-frequency = <33000000>;
controller-data {
nvidia,enable-hw-based-cs;
nvidia,rx-clk-tap-delay = <0x11>;
};
};
};

dmesg | grep c260000:

[ 0.863374] iommu: Adding device c260000.spi to group 9

Thanks!
/ Tobias

Hi tobias.johansson1,

What’s your Jetpack version in use?

May I know what’s your use case for SPI? How do you configure SPI and what’s the data you send?

Have you also verified if the devkit would hit the same issue?
If so, could you provide the detailed reproduce steps?

Please compare the dmesg in this period and share it for further check.

Hi! Here’s some answers and further information.

Jetpack version: 32.7.4

We have verified with a NON-Industrial AGX that it works as expected. So it seems to be an Industrial specific issue.

The diff between dmesg in a case where it works, and a case where it does not work, is what i included in the initial/first post. When it works, nothing is shown in dmesg during the active period.

Short description on use case: We are using the SPI to transfer 10 Bytes to/from a device with a frequency of 1Hz.
For our simplified tests, we are “just” using a short c-program, (not complete) extracts below.

According to the old issue, before we never got it working at all on an Industrial AGX, we solved it with:
reverting the changes made by t19x-common-platforms/tegra194-no-pll-aon-clock.dtsi and disabling nodes sce@b000000 and tegra-hsp@b150000” (Spi@c260000 on Jetson AGX Xavier Industrial - #6 by mattias.johansson)

include <linux/spi/spidev.h>
static void transfer(int fd, uint8_t const *tx, uint8_t const *rx, size_t len)
{
int ret;

struct spi_ioc_transfer tr = {
    .tx_buf = (unsigned long)tx,
    .rx_buf = (unsigned long)rx,
    .len = len,
    .delay_usecs = delay,
    .speed_hz = speed,
    .bits_per_word = bits,
};

ret = ioctl(fd, SPI_IOC_MESSAGE(1), &tr);
if (ret < 1)
    pabort("can't send spi message");

}

static void spi_init(int fd)
{
int ret = 0;

/*
 * spi mode
 */
ret = ioctl(fd, SPI_IOC_WR_MODE, &mode);
if (ret == -1)
    pabort("can't set spi mode");

ret = ioctl(fd, SPI_IOC_RD_MODE, &mode);
if (ret == -1)
    pabort("can't get spi mode");

/*
 * bits per word
 */
ret = ioctl(fd, SPI_IOC_WR_BITS_PER_WORD, &bits);
if (ret == -1)
    pabort("can't set bits per word");

ret = ioctl(fd, SPI_IOC_RD_BITS_PER_WORD, &bits);
if (ret == -1)
    pabort("can't get bits per word");

 // max speed hz     
ret = ioctl(fd, SPI_IOC_WR_MAX_SPEED_HZ, &speed);
if (ret == -1)
    pabort("can't set max speed hz");

ret = ioctl(fd, SPI_IOC_RD_MAX_SPEED_HZ, &speed);
if (ret == -1)
    pabort("can't get max speed hz");

}

int main(int argc, char** argv)
{
// open spidevX.X
int fd = open(device, O_RDWR);
spi_init(fd);

while(true)
{

transfer(fd, default_tx, default_rx, sizeof(default_tx));

}
}

Thanks!

Just as an update. Behaves the same (crashes if we are trying to use the spi quickly after boot) on the dev-kit as well (with an Industrial AGX).

There is no update from you for a period, assuming this is not an issue any more.
Hence we are closing this topic. If need further support, please open a new one.
Thanks

Do you mean that you would hit the issue only with AGX Xavier Industrial + R32.7.4?

Could you help to verify if you could reproduce the issue with R35.4.1 on the devkit (with AGX Xavier Industrial)?

Please share your current device tree for further check.