The 1st bug is the same as what reported here: https://devtalk.nvidia.com/default/topic/1002582/chip-select-1-stuck-low-on-spi1/ . 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.
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.
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.
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?
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.
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?
It’s unthinkable that after more than one and half year this bug is still not fixed in the latest JetPack release! I checked that the above mentioned patch code was not in the device driver source code associated with the JetPack 4.6. May someone in NVidia please let us know when Nvidia will fix the problem in official release?