imx8mp ECSPI1 SCLK is not continuous

[arunlee]

Hi,

We have an im8mp board (solidrun) based HW running yocto zeus. I am trying to configure the ecspi1 to use BME280 sensor.

Here is my device tree configuration:

From imx8mp.dtsi:

                        ecspi1: spi@30820000 {
                                #address-cells = <1>;
                                #size-cells = <0>;
                                compatible = "fsl,imx8mp-ecspi", "fsl,imx6ul-ecspi";
                                reg = <0x30820000 0x10000>;
                                interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
                                clocks = <&clk IMX8MP_CLK_ECSPI1_ROOT>,
                                         <&clk IMX8MP_CLK_ECSPI1_ROOT>;
                                clock-names = "ipg", "per";
                                assigned-clock-rates = <80000000>;
                                assigned-clocks = <&clk IMX8MP_CLK_ECSPI1>;
                                assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_800M>;
                                dmas = <&sdma1 0 7 1>, <&sdma1 1 7 2>;
                                dma-names = "rx", "tx";
                                status = "disabled";
                        };

From imx8mp-hummingboard-pulse.dts

&ecspi1 {
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_ecspi1>;
        cs-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>;
        status = "okay";

        spidev@0x00 {
            compatible = "linux,spidev";
            reg = <0>;
            spi-max-frequency = <10000000>;
            status = "okay";
        };

        pinctrl_ecspi1: ecspi1grp {
                fsl,pins = <
                        MX8MP_IOMUXC_ECSPI1_SCLK__ECSPI1_SCLK           0x06
                        MX8MP_IOMUXC_ECSPI1_MOSI__ECSPI1_MOSI           0x06
                        MX8MP_IOMUXC_ECSPI1_MISO__ECSPI1_MISO           0x06
                        MX8MP_IOMUXC_ECSPI1_SS0__GPIO5_IO09             0x86
                >;
        };

I get the spidev

lrwxrwxrwx  1 root root 0 Nov 24 10:05 spidev1.0 -> ../../devices/platform/soc@0/30800000.bus/30820000.spi/spi_master/spi1/spi1.0/spidev/spidev1.0
root@vision-platform:~# ls /dev/spidev1.0
/dev/spidev1.0
root@vision-platform:~#

I am trying the spi_fdx.c adapted to the device address for BME280.

What i am seeing is that as soon as the address byte is sent out the SCLK is stopped, which makes the BME280 unable to send any data back.

What do i need to change in the device configuration so that the CLK is active as long as the CS is low?

regards

Arun

[kshitij_shah]

@arunlee What is the address byte sent out ? Does CS pin return to idle state at the same time? If you set master to send 5 bytes data, master will send 5, even there is no slave device connected on the spi bus. The master will just receive 0x0 or 0xff in this case. 

[kshitij_shah]

@arunlee Can you please try the latest BSP as SPI DMA is supported from 5.10. Alternatiively, you can also try the INT mode.

[arunlee]

@kshitij_shah  is there a known issue with 5.4? ecspi2 is working fine though

[kshitij_shah]

@arunlee Can you please keep pad settings as ecspi2, such as:

pinctrl_ecspi1: ecspi1grp {
                fsl,pins = <
                        MX8MP_IOMUXC_ECSPI1_SCLK__ECSPI1_SCLK           0x82
                        MX8MP_IOMUXC_ECSPI1_MOSI__ECSPI1_MOSI           0x82
                        MX8MP_IOMUXC_ECSPI1_MISO__ECSPI1_MISO           0x82
                        MX8MP_IOMUXC_ECSPI1_SS0__GPIO5_IO09             0x40000
                >;
        };

[kshitij_shah]

@arunlee Can you please provide all changes made by you including spi_fdx.c/dts and any other changes. We will try to reproduce issue. Also the test command used.

[arunlee]

There is no change in behavior. In fact i had started with these as you have mentioned before ending up with what i pasted in the query.

I am afraid there is something in solidrun SoM which makes this behavior. escpi2 works fine with the same configurations.

[kshitij_shah]

@arunlee Please provide following:

Please help to get:

1. Kernel version they use

2. Changes to kernel

3. Their test case/ command

4. Any special settings like CPOL/CPHA/CS_POL_HIGH/Bit per word...

5. Which mode did they use, PIO or DMA mode?

6. How much data did you send every time?

Do they see any logs when encounter the issue?

[arunlee]

1. Kernel version they use

  5.4.70-2.3.0

2. Changes to kernel

Solidrun Yocto layer: https://github.com/SolidRun/meta-solidrun-arm-imx8/tree/zeus-imx8mp

Solidrun doesn't use ecspi1 at all. even in the hummingboard they have used escpi2.

3. Their test case/ command

4. Any special settings like CPOL/CPHA/CS_POL_HIGH/Bit per word...

5. Which mode did they use, PIO or DMA mode?

6. How much data did you send every time?

To the above meta layer we have added the following changes in device tree for ecspi1 and enabled bmp280 kernel driver.

&ecspi1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi1>;
cs-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>;
/*cs-gpios = <&gpio1 5 GPIO_ACTIVE_LOW>;*/
status = "okay";
#address-cells = <1>;
#size-cells = <0>;

bmp280@0 {
compatible = "bosch,bmp280";
reg = <0x0>;
spi-max-frequency = <500000>;
default-oversampling = <1>;
status = "okay";
};

};

        pinctrl_ecspi1: ecspi1grp {
                fsl,pins = <
                        MX8MP_IOMUXC_ECSPI1_SCLK__ECSPI1_SCLK           0x82
                        MX8MP_IOMUXC_ECSPI1_MOSI__ECSPI1_MOSI           0x82
                        MX8MP_IOMUXC_ECSPI1_MISO__ECSPI1_MISO           0x82
                        MX8MP_IOMUXC_ECSPI1_SS0__GPIO5_IO09             0x40000
                >;
        };

Default bmp280 driver tries to read the address 0xD0 to know the chip id.

Do they see any logs when encounter the issue?

Driver failed in probe. The driver is expecting a value of 0x58 instead gets only 0xFF

[kshitij_shah]

@arunlee did a test on 8mp, and I haven't found any problems so far. I tested it with spidev_test, this is the waveform of the test. The transmission of both modules is normal. The CS line is also normal. Please confirm that the connection between MISO and MOSI and the slave is correct. Also, can you test it with imx8mp ?

[kshitij_shah]

@arunlee Attached is the waveform generated for imx8mp. Also looking at your waveform, the MISO does not have data on line. Or the MISO looks is set as Open Drain? The rising edge is so slow.

[arunlee]

@kshitij_shahcould you please try transfering more than 2 bytes (1k bytes) and share the wave forms?

[kshitij_shah]

 @arunlee Attached is the waveform. Also, the waveform provided by you, the data sent by the host's three wires (MOSI, SCK, CS) are all correct.

[kshitij_shah]

@arunlee  Can you provide a patch for any changes made to kernel. Also, what platform are you using to test ecspi1, as i noticed you say hummingboard uses ecspi2 ?

[arunlee]

@kshitij_shah  we are using hummingboard pulse (https://www.solid-run.com/embedded-industrial-iot/nxp-i-mx8-family/hummingboard-m/ ) and imx8mp SOM (https://www.solid-run.com/embedded-industrial-iot/nxp-i-mx8-family/imx8m-plus-som/)

Solidrun kernel changes can be seen in the github https://github.com/SolidRun/meta-solidrun-arm-imx8/tree/zeus-imx8mp/recipes-kernel/linux/linux-imx

We have added the ECSPI1 device tree changes as pasted before.

[igorpadykov]

Hi Arun

reason may be that FIFO become empty, as described on below links:

https://community.nxp.com/t5/i-MX-Processors/imx8-ecspi-Master-Mode-with-SS-CTL-Control/m-p/984674

https://community.nxp.com/t5/i-MX-Processors/Control-SPI-SS-CTL-for-single-burst-operation/m-p/15994...

Also just for test one can disable dma, remove escpi dma entries from dts file.

Spidev is described on

https://variwiki.com/index.php?title=DART-MX8M_SPI

https://www.emcraft.com/som/imx-8m/accessing-spi-devices-in-linux

Best regards
igor

[arunlee]

Thanks @igorpadykov I will try out stuff from those links. But what is puzzling me is that ecspi2 works fine without any modifications. All we need to do was to make the ECSPI2_SSO as a output by modifying the GPIO register.

[arunlee]

I tried using the kernel driver for bm3280, and the driver failed in probe with FF received from the device.

Nov 30 09:19:23 vision-platform kernel: spi_imx 30820000.spi: probed
Nov 30 09:19:23 vision-platform kernel: bmp280 spi0.0: spi0.0 supply vddd not found, using dummy regulator
Nov 30 09:19:23 vision-platform kernel: bmp280 spi0.0: spi0.0 supply vdda not found, using dummy regulator
Nov 30 09:19:23 vision-platform kernel: bmp280 spi0.0: bad chip id: expected 60 got ff
Nov 30 09:19:23 vision-platform kernel: bmp280: probe of spi0.0 failed with error -22

The signal looks the same that there is no clock persisting.

Any help in fixing this would be really helpful. A simple SPI device is not working through ecspi1.