Chip Select Toggling Between Bytes

[mwso_soe]

I am using an i.MX8Q with NOR flash connected to the lpspi3 interface.

Here is the relevant portion of my devicetree

&lpspi3 {
    pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_spi3>;
	#address-cells = <1>;
	#size-cells = <0>;
	status = "okay";
	
    // S25FL256LAGNFI010
    flash1: flash@0 {
        reg = <0>;
        #address-cells = <1>;
        #size-cells = <1>;
        compatible = "spansion,s25fl256l", "jedec,spi-nor";
        spi-max-frequency = <100000>;
        spi-tx-bus-width = <1>;
        spi-rx-bus-width = <1>;
        
        // Arbitrary demo partition 0
        partition@0 {
            label = "spi_flash_1_part0";
            reg = <0x0 0x100000>;
        };

        // Arbitrary demo partition 1
        parition@1 {
            label = "spi_flash_1_part1";
            reg = <0x100000 0x300000>;
        };
    };
};

 
When the system boots and tries to discover the flash with JEDEC command 0x9F, the Chip Select is toggled between bytes causing the chip not to respond.

I cannot find any configuration information that I may be missing to resolve this, nor have I found any threads on the forums that seem to cover similar issues.

[jimmychan]

You may try to config the iomux of the cs pin as gpio pin and then use "cs-gpios" to set it up in device tree file.

For example:

https://source.codeaurora.org/external/imx/linux-imx/tree/arch/arm64/boot/dts/freescale/imx8qm-lpddr...

[mwso_soe]

@jimmychanI went ahead and implemented the GPIO chip select as described in the link you sent, and after doing so I still see the same behavior of the CS0 signal as I saw before.

[jimmychan · Accepted solution]

FYI. https://community.nxp.com/t5/i-MX-Processors/ECSPI-multibyte-transfer-without-CS-toggle/m-p/1029179

You could try the cs_change=0.

[dvega]

Which file is the one you change the "cs_change=0" line?

[mwso_soe]

At least looking at the spi-fsl-lpspi.c driver (I picked an arbitrary kernel version), there is no recognition of any `cs_change` parameter that I can see, so that portion of the accepted response was irrelevant to me.

For context on my work around this issue, I ended up just not being able to use the hardware chip select signals necessitating a redesign of our board.

I experimented with patching the driver to change the chip select behavior, but the lift was too large given the state of the project and we were fortunate enough that the device connected to the only pin that did not have a GPIO alternate function was not critical.

What I believe was being alluded to by @jimmychan was to add that parameter to the device tree node using the lpspi interface. However, a quick search of the Linux kernel I do not see any evidence of `cs_change = 0` being used in any device tree .dts file, only some spi drivers using it as an internal data structure. So, I still don't think it is much of a solution here, since the chip select control issue is due to the lpspi hardware on the i.MX8, not the driver in Linux. Instead, one would need to figure out the correct register configurations (if any) for the lpspi driver to set in order to disable this behavior.

Hopefully this is helpful for you @dvega.

[mwso_soe]

Thanks for the quick reply!

I will try this and see if it works. One thing I am most concerned about is exactly why this is happening in the first place.

I tried looking at the lpspi drive source code but don't see anything that suggests the chip select would be pulled high between bytes. https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/spi/spi-fsl-lpspi.c?h=imx_4.19.35_...

[mwso_soe]

@jimmychanI attempted converting the first flash's chip select to a GPIO chip select with no luck, the signal was still toggling between bytes. I am also not sure I will be able to use GPIOs for all the chip selects, since the CS1 pin does not seem to have an alternate GPIO function.

My SoM was damaged before I could take meaningful logic captures, but I will share more information once I restore my hardware to working order.

[mwso_soe]

Better late than never, but converting to GPIO chip select did resolve this problem.