LS1046a SPI Clock Problem

[srechermann]

I´m, planning to use the SPI- Controller of the LS1046a. In a first test setup, I made some measurements at the Testpoints TP9 (SPI_CLK) and TP10 (SPI_SOUT) of the Eval Board LS1046ARDB.

 

To be able to send data via the SPI- Controller from Linux Userspace, I added a "spidev" device to the devicetree and compiled the spidev_test tool from https://github.com/nxp-qoriq/linux/blob/lf-5.15.y/tools/spi/spidev_test.c

DeviceTree:

&dspi {

            bus-num = <0>;

            status = "okay";

            spi1: spi@CS0 {

                        compatible = "rohm,dh2228fv";      # in compatibility list of spidev.c

                        reg = <0x0>;

                        spi-max-frequency = <50000000>;

                        #address-cells = <1>;

                        #size-cells = <1>;

            };

With this modification and the following command, I`m able to see outcoming data on SPI_SOUT.

./spidev_test -D /dev/spidev0.0 -v -p "\x00\x01\x02\x03\x04\x05\x06\x07\x08\x09" -H

With a short between SPI_SOUT and SPI_SIN, I got following output:

./spidev_test -D /dev/spidev0.0 -v -p "\x00\x01\x02\x03\x04\x05\x06\x07\x08\x09" -H

spi mode: 0x1

bits per word: 8

max speed: 500000 Hz (500 kHz)

TX | 00 01 02 03 04 05 06 07 08 09 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  |..........|

RX | 00 01 02 03 04 05 06 07 08 09 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  |..........|

So, all fine until now.

But there is some unexpected behavior on the SPI Bus.

Depending on the size of the Tx data buffer, I observe a much too short negative clock phase (~16ns instead of 1/(2*500MHz) = 1us)).

 

I used an Oscilloscope to distinguish, if a whole negative clock phase is just to short or if there is only one longer positive clock phase with a unwanted glitch.

But you can already see that MOSI changes from 1 to 0 during these short 16ns Pulse.

I used two probes at the clock. The yellow one with a Bandwidth of 200MHz and the orange one with a Bandwidth of 5MHz only. A third probe was connected to SPI_SOUT (TP9).

If I select the yellow trace (BW: 200MHz) as a Clk source for the SPI- Analyzer, the interpreted data are equal to the transmitted.

 

So, no surprise: As far as I select the filtered orange trace as a clock, there are missing Bits in the analyzed data:

 

Do you already know this behavior? Is a workaround available to get a “clean”, uniform clock cycles?

I would really like to use the SPIDEV Kernel Driver as an entry point for further development.

BR

Simon

[Mark9876 · Accepted solution]

I wonder if you issue is related to this:  https://github.com/torvalds/linux/commit/c5c31fb71f16ba75bad4ade208abbae225305b65

I'm having issues where I am beginning to doubt the accuracy of my SPI reads and writes also (in my case relative to the operation of the max3109 kernel driver).  My hardware is not easy to probe with an oscilloscope so I can't prove it like you have.  I would be curious if applying the above patch fixes your problem.

[valokuvaaja]

Hello, everyone!
I've encountered with the same problem on LS1046AFRWY board: "merged" pulses on SCLK in every SPI transaction (see the photo below), and the absence of tCSC and tASC delays (not shown). Linux 5.10.52, Yocto Kirkstone release.

SCLK is yellow, MOSI is pink, MISO is green.
In the following photo SCLK is zoomed in.

The problem is gone after applying the patch. 
Yellow is still SCLK, and pink is CS1 now

Thank you so much!

[srechermann]

Thanks a lot! This patch solved the problem.

[LFGP]

please confirm that you have the spidev node under dspi node, it must be something like:

under dspi node:

spidev0: spi@0

{ reg = <0>; compatible = "rohm,dh2228fv"; spi-max-frequency = <3000000>; }

[srechermann]

Yes that's correct. The original dspi node is defined like this in the fsl-ls1046a.dtsi.

dspi: spi@2100000 {
	compatible = "fsl,ls1021a-v1.0-dspi";
	#address-cells = <1>;
	#size-cells = <0>;
	reg = <0x0 0x2100000 0x0 0x10000>;
	interrupts = <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>;
	clock-names = "dspi";
	clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
					QORIQ_CLK_PLL_DIV(2)>;
	spi-num-chipselects = <5>;
	big-endian;
	status = "disabled";
};

in the board specific fsl-ls1046a-rdb.dts which includes the fsl-ls1046a.dtsi of the ls1046a soc I am referencing the dspi node and modify it like that.

&dspi {
	bus-num = <0>;
	status = "okay";
	
	spi1: spi@CS0 {
		compatible = "rohm,dh2228fv";
		reg = <0x0>;
		spi-max-frequency = <1000000>;
		#address-cells = <1>;
		#size-cells = <1>;
	};
};

[LFGP]

dear @srechermann  ,

please take note that you are using the  spi-max-frequency = <50000000>; #50 MHz

could you please explain the reason to use 5MHz as clock

[srechermann]

I changes the max-frequency in the device tree to: spi-max-frequency = <1000000>; # 1MHz
The behavior is still the same as I showed in my original post. The user space application (in my case spidev_test) sets the frequency (500kHz) independently from the spi-max-frequency. The clock problem with the short 16ns (maybe 20ns) pulse is still the same.

[srechermann]

Like you can see in the spidev_test output and the screenshots of the oscilloscope in the previous post, the clock speed is set to 500kHz (one clock cycle = 2us) by the spidev_test tool. This works for the most of the time except these sporadically appearing 16ns pulses. Limiting the bandwith of the red channel of the oscilloscope to 5MHz was just to show what could happen when the SPI Slave overlooks this very short 16ns pulse and therefore samples the data incorrectly. So the general problem I wanted to show was the faulty SPI CLK with the much too short 16ns pulse.