SPI failure when multiple perihperals are using the bus

We have two SPI peripherals on the Jetson Nano board:

Have below command to have system run as performance mode to try.

sudo nvpmodel -m 0
sudo jetson_clocks

How will changing the mode of the system resolve a potential race condition?
Also, these tools are not available on the custom Yocto image that we’re using - is there a repository from where we can download them onto the target?

It’s built in tools if using L4T package.

Got it. I assume nvpmode was a type and nvpmodel was the actual command?

Yes, sorry for the typo.

jetson_clocks reports:
Can’t access Fan!
What is the meaning of this?

The bug persists, but I’m not sure whether jetson_clocks command achieved anything, due to the reported error.

Please have a try below patch.

Subject: [PATCH 1/2] drivers: spi: fix CS behavior in case of 2 CS

The CS state was changed before the completion of
transfer and default state was being written this
was causing an issue. CS should be moved to inactive
state before changing active CS.

Bug 3378387

Change-Id: I1f0ead6c25b7086535f53e2fe232b604b208b5ad
Signed-off-by: Vishwaroop A <va@nvidia.com>
---
 drivers/spi/spi-tegra114.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra114.c
index 9a4abb4..2aadf42 100644
--- a/drivers/spi/spi-tegra114.c
+++ b/drivers/spi/spi-tegra114.c
@@ -1490,10 +1490,8 @@ static int tegra_spi_transfer_one_message(struct spi_master *master,
                msg->actual_length += xfer->len;

 complete_xfer:
-               if (prefer_last_used_cs)
                        cmd1 = tspi->command1_reg;
-               else
-                       cmd1 = tspi->def_command1_reg;
+
                if (ret < 0 || skip) {
                        if (cstate && cstate->cs_gpio_valid)
                                gpio_set_value(spi->cs_gpio, gval);
--
2.1.4

@ShaneCCC I’ve tried this patch, but it doesn’t fix the problem and what is more, after this patch CAN transfers are corrupted. The receiver reports same data multiple times when sender send them only once, e.g.:
sender:

  can0  06D#6A.7B.2D.52.7F.A9.19.7A
  can0  3C8#BF.46.B9.15.8E.88.05.5A
  can0  49A#01.8E.CD.74
  can0  46D#B4.05.A4.14
  can0  3FC#86.60.57.4B.90.3C.F1.76
  can0  53B#43.08.1D.3B.85.1B.4A.6B
  can0  4A1#9E.60.5B.49.09.F2
  can0  31B#2A.B1.B6.05.88.BB.9A

receiver:

  can0  06D   [8]  6A 7B 2D 52 7F A9 19 7A
  can0  06D   [8]  6A 7B 2D 52 7F A9 19 7A
  can0  06D   [8]  6A 7B 2D 52 7F A9 19 7A
  can0  06D   [8]  6A 7B 2D 52 7F A9 19 7A
  can0  3C8   [8]  BF 46 B9 15 8E 88 05 5A
  can0  3C8   [8]  BF 46 B9 15 8E 88 05 5A
  can0  3C8   [8]  BF 46 B9 15 8E 88 05 5A
  can0  49A   [4]  01 8E CD 74
  can0  46D   [4]  B4 05 A4 14

Could share the dtb file and also enable the dump_register #define that will dump the registers
and enable the debug logs using the below commands on the target
echo -n “file drivers/spi/spi-tegra114.c +p” > /sys/kernel/debug/dynamic_debug/control
echo 8 > /proc/sys/kernel/printk

tegra210-p3448-0002-p3449-0000-b00.dtb (241.1 KB)
Device tree is here, I will upload the logs shortly.

boot_20220615_debug.zip (244.9 KB)
And here are the logs.

@nikola.jelic can you please share the exact BW requeriments from both, the MCP2518FD and CMX655D. How much data is transferred and at what speeds?

MC2518 communicates on SPI with 20MHz bus frequency, while CAN is 100k.
Codec currently operates at 100kHz, but it could go faster.

Hi, we just check those logs and didn’t found any error about SPI driver.
Any reason to tell the issue cause by SPI transfer?

Could you check if able reproduce the issue by spidev loopback test on two SPI controller simultaneously.

We tried out two different approaches in debugging, and both yielded good results:

  • Increasing the clock speed for audio codec to 20MHz
  • introducing a fix in tegra spi driver to handle empty buffers

Both allowed us to have 12+ hours of testing without a single error.
We will send you the patch for the tegra driver as soon as we finish the integration on our end.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.