Two SPI bugs on Jetson Nano

The 1st bug is the same as what reported here: . This problem might only occur when 2 CSs are used. In my case, they are SPI1_CS0 (pin 18) and SPI1_CS1 (pin 16). One SPI slave keeps CS low prevents the other slave from working correctly in timely fashion.

As shown in the attached picture, the 2nd bug is that in SPI mode 3, the respective timing of CS and CLK are wrong most of the time and are drifting with respect to each other so that reading from SPI slave returns incorrect values most of the time and only returns correct values when the drifting happens to make CS and CLK timing matches the standard timing.

In the attached image, upper trace is SPI0_SCK (pin 23) and lower trace is SPI0_CS0 (pin 24). The expected timing in mode 3 is that CS goes low when SCK is high. In the attached picture, during transfer, SCK frequency is 1MHz.

BTW, spidev_test passed in all modes, and I don’t think spidev_test covers the timing.

Thanks for your report. We have report this to the internal developer to check it.

The first bug makes our design impractical now as we initially wanted to use all 4 spidev devices. So this bug is blocking us, if possible, please ask your internal developers to fix it first.



May anyone share status of NVidia internal developers’ investigation into the above reported problems? Will they be fixed any time soon?

Here I’d like to report the 3rd bug: when using GPIO pins as chip selects, similar problem occurred, and the error message reported writing error.

BTW, is it possible to configure to enable more than 4 chip selects using GPIO pins on Jetson Nano?

Please also ask internal developers to investigate the 3rd bug.


Could you try below patch to verify it.

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

-               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);

Hi Shane,

Which problem will be fixed by the above patch? I don’t know the procedure to try out the patch.

Has any QA in NVidia reproduced the above 3 bugs? Has anyone in NVidia tried out the above fix?


The patch description as below. Our developer repo the issue and provide this fix to you to verify.

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.

Hi Shane,

Thanks for the info, and I’m glad to have a possible fix! May you please provide DETAILED steps to try out the patch? I’m new to this.

Is there any progress with SPI mode 3 not working bug? This bug prevents some sensors from being used in my project.


I think you need to probe the CS to confirm it.

Just confirm this change fix the mode 3 problem as well.

Hi to all,

I’ve started to evaluate SPI bus on Jetson Nano. I’ve encountered into a problem mentioned as 1st bug. The problem is when using CS pins as native HW CS.

Here are my observations.
SPI1 pinmuxed to hw spi. (tested with backloop test, spidev_test)

  • When using only one SPI subdevice, HW CS_0 is OK
  • Adding a second subdevice, CS_0 is tied to low, CS_1 is OK
  • Configuring all CS as GPIO, everything is OK

I’ve tested SPI2 bus also and it ended up with same results.
My question is why native CS doesn’t work in multi subdevice configuration. Is it a known issue?

L4T: 32.3.1
Platform: Jetson Nano Dev Kit b00

Hi to all,
L4T: 32.4.3

I’ve tested a spi can device using double MCP2518FD,which connect to Jetson Nano with a single SPI bus(hw spi1, sw spi0) and it’s 2 chip selects (cs0 & cs1).

And a strange condtion I meet is:

tegra210 sometimes activates more than one chip-selects
the same time if the controller works interleavely between
modes hw_based_cs and sw_based_cs.

So I add a device-tree option nvidia,always-hw-cs to around this problem,
which make the double CAN works properly on hw-cs mode.

Later I researched the can and spi driver, found than the spi driver has a bug about handling cs_change.
fixed in the commit

hope you @ShaneCCC @kayccc can merge these patches.

Could you help to verify those changes from below link for SPI functionality.

Hi @ShaneCCC
I veified these two patches on Jetson Nano(Tegra 210) which I have only.

After these two patch applied and below changes

static struct tegra_spi_chip_data tegra210_spi_chip_data = {
        .intr_mask_reg = true,
        .set_rx_tap_delay = false,
        .slcg_support = false,
-       .cs_active_delay_hw = false,
+       .cs_active_delay_hw = true,

The device-tree option nvidia,cs-inactive-cycles works, CS will inactive between double 8-clocks group (8 bits per packet).

the option nvidia,clk-delay-between-packets haven’t any effect, the SPI clocks are continous during CS stay in active state.
The options nvidia,cs-setup-clk-count & nvidia,cs-hold-clk-count also haven’t any effect by probing the CS signals.
BTW, I don’t know their units.
The speed of hardware chip-select really much faster than using cs-gpios.

Does anyone know if all of the above mentioned patches are in JetPack 4.4.1 release? In other words, are the problems reported here fixed in JetPack 4.4.1 release?


i try those changes ,but dmesg
mcp251x spi0.1: Cannot initialize MCP2515. Wrong wiring?
[ 7.139162] mcp251x spi0.1: Probe failed, err=19
Before the change, I have two ways: can. All the data will shift, I don’t know why. Can you give me some solutions;
For example,have some 80
can1 111 [8] 7E 00 00 00 00 00 00 00
can1 111 [8] 7F 00 00 00 00 00 00 00
can1 111 [8] 80 00 00 00 00 00 00 00
can1 111 [8] 81 00 00 00 00 00 00 00
can1 111 [8] 82 80 00 00 00 00 00 00
can1 111 [8] 83 00 00 00 00 00 00 00
can1 111 [8] 84 80 00 00 00 00 00 00
can1 111 [8] 85 00 00 00 00 00 00 00
can1 111 [8] 86 00 00 00 00 00 00 00
can1 111 [8] 87 00 00 00 00 00 00 00
can1 111 [8] 88 00 00 00 00 00 00 00

Please help to open a new topic for your issue. Thanks