Jetson Nano SPI mode 3 issue

[jbzp00y]

Hello,

I’m trying to communicate with an IMX264 sensor on a custom board. The problem is that I had to use SPI mode 3 but the CLK signal didn’t stay at high level when not used.

Like we can see on the oscilloscope (nCS in blue and CLK in yellow), the chip select falls and then the clock rises. In SPI mode 3 value are taken on rising edge of the CLK so I want that CLK rises before chip select falls. How can I do this?
It’s a GPIO chip select.

I try to change these parameters without success:

imx264@0 {
...
    controller-data {
				nvidia,tx-clk-tap-delay = <????>;
				nvidia,cs-setup-clk-count = <????>;
				nvidia,cs-hold-clk-count = <????>;
			};
...
};

How these parameters works? Do you have more informations?

I saw many post about this problem but I can’t resolve this. I the last one the solution is to had an inverter and change the mode. It’s not possible on my board.

SPI CS issue

Hi Guys, I’m experiencing a weird problem with SPI.0 using spidev. Here’s a couple of points: My kernel is R24 (i cannot use the latest Jetpack as all my custom drivers break) My SPI clock rate is set to 9.5MHz (this works fine) I’m using hardware CS What I observe is: CS pulls low (enables) - as expected data is clocked out @ 9.5MHz - as expected CS stays low for additional 31uS before it goes high - not expected! My device-tree is setup like this: spi0_0 { #address-cell…

How to set SPI CS(chip select) timing?

Hi ShaneCCC: It still can not solve this issue. On the other hand, I find this link. https://devtalk.nvidia.com/default/topic/1029410/jetson-tx1/spi-cs-issue/ Do I need to patch spi-tegra114.c file or not? This is my modification in device tree tegra210-porg-p3448-common.dtsi spi@7000d400 { /* SPI 1 to 40 pin header */ status = "okay"; num-cs = <2>; cs-gpios = <&gpio TEGRA_GPIO(C, 3) GPIO_ACTIVE_LOW>, <&gpio TEGRA_GPIO(C, 4) GPIO_ACTIVE_LOW>;…

SCK goes idle after CS in SPI mode 3 when changing transaction lengths

I have C++ code using spidev0.0 at 10Mhz and SPI mode 3. I notice that whenever the SPI transaction is a different length than the previous transaction the Chip Select is going active (low in this case) before the clock goes idle (high). SPI requires the clock to be idle before setting CS active, otherwise the clock going idle is seen as the first clocking edge. If I change my code to always use the same transaction length the issue is not present (but my performance is much worse). [SPI Trac…

Thank you.

Jean

Edit: I found parameters that partially resolves my problem. The problem is only resolved once, the first SPI transfer.

controller-data {
				nvidia,tx-clk-tap-delay = <16>;
				nvidia,cs-setup-clk-count = <16>;
				nvidia,cs-hold-clk-count = <0>;
			};

1: The IMX264 responds.

2: The IMX264 does not respond.

3: The IMX264 does not respond.

[ShaneCCC]

What’s the version?

[jbzp00y]

tegra-l4t-r32.4.2. I just edit my first message

[jbzp00y]

I resolved my issue. I added a sleep before the gpio_set_value in the tegra_spi_setup_transfer_one function.

if (cstate && cstate->cs_gpio_valid) {
			int gval = 0;

			if (spi->mode & SPI_CS_HIGH)
				gval = 1;

			usleep_range(2,4);
			gpio_set_value(spi->cs_gpio, gval);
		}

[jecraig]

Jean,

The SPI ports on the 40-pin header are software emulated and there is a bug in that software that causes the problem you are seeing. It is the exact same problem I saw.

Nvidia support pointed me to a kernel patch to try, but I never did. Instead I used a standard inverter on the clock so I could use one of the SPI modes that didn’t show the bug (any mode where CLK is idle low). As long as the inverter is reasonably fast (most are) then everything works very well.

I used:

SN74LVC1GU04DBVR | Digi-Key Electronics

If you can’t use the inverter trick I suggest you try that kernel patch. The link is in that thread you found me from.

Sorry I can’t be of more help,

–Jesse

[jbzp00y]

Hello,

I tried this patch without any success.

[jecraig]

|

jbzp00y
March 10

|

• | - |

Hello,

I tried this patch without any success.

Visit Topic or reply to this email to respond.

To unsubscribe from these emails, click here.