Inconsistent Chip Select (CS) Assertion in LPSPI on RT1060EVKB

[ofirshe]

Hi,

I'm experiencing an issue with the Chip Select (CS) line on the LPSPI peripheral of the RT1060 microcontroller. The problem is that the CS is not being held low throughout the entire SPI transaction. Instead, it's toggling up and down with each clock cycle, as you can see in the waveform attached below.

Device Tree Declaration:

pinmux_lpspi1: pinmux_lpspi1 {
					phandle = < 0x14e >;
					group0 {
						pinmux = < &iomuxc_gpio_sd_b0_01_lpspi1_pcs0 >, < &iomuxc_gpio_sd_b0_00_lpspi1_sck >, < &iomuxc_gpio_sd_b0_03_lpspi1_sdi >, < &iomuxc_gpio_sd_b0_02_lpspi1_sdo >;
						drive-strength = "r0-6";
						slew-rate = "slow";
						nxp,speed = "100-mhz";
					};
				};

&lpspi1 {
	status = "okay";
	pinctrl-0 = <&pinmux_lpspi1>;
	pinctrl-names = "default";
	si5403: spi-dev-si5403@0 {
		compatible = "skyworks,si5403";
		status = "okay";
		spi-max-frequency = <250000>;
		reg = <0>;
	};
};

In the waveform attached, you can see that the CS line is not consistently asserted during the transaction. Instead of staying low throughout, it toggles every clock cycle. I expect the CS to remain asserted (low) for the duration of the transaction and only deassert once the transaction completes.

Here’s the driver code I’m using:

#define DT_DRV_COMPAT skyworks_si5403

#include <errno.h>
#include <zephyr/device.h>
#include <zephyr/drivers/spi.h>
#include <zephyr/sys/byteorder.h>
#include <zephyr/sys/util.h>
#include <zephyr/kernel.h>
#include <zephyr/sys/__assert.h>
#include <zephyr/logging/log.h>
#include <zephyr/drivers/counter.h>
#include <zephyr/sys/timeutil.h>
#include <zephyr/sys/util.h>


LOG_MODULE_REGISTER(si5403);

/*
 * Make sure that this driver is not initialized before the spi bus is available
 */
BUILD_ASSERT(CONFIG_SI5403_INIT_PRIORITY > CONFIG_SPI_INIT_PRIORITY);

#define SI5403_SPI_OP  (SPI_WORD_SET(8) | SPI_OP_MODE_MASTER | SPI_MODE_CPOL | SPI_MODE_CPHA)

struct si5403_config 
{
    const struct spi_dt_spec bus;
};

static int si5403_init(const struct device *dev)
{
	const struct si5403_config *cfg = dev->config;
	int ret;

	if (!spi_is_ready_dt(&cfg->bus)) 
    {
		LOG_ERR("SPI bus %s not ready", cfg->bus.bus->name);
		return -ENODEV;
	}

    uint8_t check_for_CTS_request[] = { 0xD0, 0x00 };
	const struct spi_buf tx_buf = { .buf = check_for_CTS_request, .len = sizeof(check_for_CTS_request) };
	const struct spi_buf rx_buf = { .buf = check_for_CTS_request, .len = sizeof(check_for_CTS_request) };
	const struct spi_buf_set tx = { .buffers = &tx_buf, .count = 1 };
	const struct spi_buf_set rx = { .buffers = &rx_buf, .count = 1 };

    while (check_for_CTS_request[1] != 0x80)
    {
        ret = spi_transceive_dt(&cfg->bus, &tx, &rx);
        if (ret < 0)
        {
            LOG_ERR("SPI transaction failed with code: %d", ret);
        }

        printf("received %d\n", check_for_CTS_request[1]);
        k_sleep(K_SECONDS(1));
    }

    printf("done!!!\n");
	
	return 0;
}

#define SI5403_DEFINE(inst)                                         \
	static const struct si5403_config si5403_config_##inst = {      \
		.bus = SPI_DT_SPEC_INST_GET(inst, SI5403_SPI_OP, 0),        \
	};                                                              \
	DEVICE_DT_INST_DEFINE(inst,                                     \
						  si5403_init, NULL,                        \
						  NULL, &si5403_config_##inst,              \
						  POST_KERNEL, CONFIG_SI5403_INIT_PRIORITY, \
						  NULL);

/* Create the struct device for every status "okay"*/
DT_INST_FOREACH_STATUS_OKAY(SI5403_DEFINE)

I’m sending a { 0xD0, 0x00 } command and expecting to receive 0x80 in the second byte of the response. However, I consistently receive 0x00 instead. This issue might be related to the inconsistent CS behavior observed.

Any suggestions or insights would be greatly appreciated.

[tbursztyka]

What SPI controller driver is this, spi_nxp_32.c ?

[ofirshe]

It's nxp,imx-lpspi, inherited from nxp_rt10xx.dtsi

[mariopaja]

@ofirshe There are some issues going around the LPSPI of RT10xx, and hopefully we see soon a reimplementation of LPSPI driver #69658 (comment)

In my projects, I have removed the <&iomuxc_gpio_xxxxxxxx_pcs0> from the pinmux and I instead I am using cs-gpio. Maybe this also helps you with the chip select issue.

Additionally, I had problems using const struct spi_buf tx_buf & const struct spi_buf rx_buf (see #69658):

[ofirshe]

Could you please explain how to properly use cs-gpios on the RT1062?
Also, what issues might arise with using const struct spi_buf tx_buf and const struct spi_buf rx_buf in my code, and what is the alternative?

[mariopaja]

Hi @ofirshe,

please have a look into #69658 (comment). Here I have showed the changes I did to the OA_TC6 driver to make it work on rt1064.

But before making such changes, please check if just the cs-gpios implementation is enough.

[ofirshe]

Even after adopting the cs-gpios property, I noticed in the signal analyzer that the data sent from the RT1060EVKB is incorrect. The buffer I'm sending is a 2-byte array: uint8_t check_for_CTS_request[] = { 0xD0, 0x00 };
However, this doesn't match the waveform observed on the MOSI line.

I look into #69658 (comment). but I’m not sure what changes I should make to my code based on the suggestions there.

Could you provide guidance?

[DerekSnell]

Hi @ofirshe ,
There is a known issue with the LPSPI driver that if using a hardware chip select, the driver may not keep the chip select asserted for the full Zephyr SPI transfer, see #16544. The cause of this is how transfers are managed in the HAL LPSPI driver. The current workaround is to use a GPIO pin for the chip select instead, using the cs-gpios property referenced above.

To use a GPIO chip select, you can refer to the mimxrt1062_fmurt6 board as a reference. Your SPI node needs a cs-gpios property selecting the GPIO pin to use. And then the pinctrl setting for that pin should use the GPIO pin mux instead of the SPI hardware chip select. For reference, the mimxrt1062_fmurt6 board configures lpspi1 like this, using GPIO3 pin23 as the GPIO:

&lpspi1 {
	status = "okay";
	pinctrl-0 = <&pinmux_lpspi1>;
	pinctrl-names = "default";
	cs-gpios = <&gpio3 23 GPIO_ACTIVE_LOW>;
	clock-frequency = <DT_FREQ_M(10)>;
};

	pinmux_lpspi1: pinmux_lpspi1 {
		group0 {
			pinmux = <&iomuxc_gpio_emc_37_gpio3_io23>,
				<&iomuxc_gpio_emc_27_lpspi1_sck>,
				<&iomuxc_gpio_emc_29_lpspi1_sdi>,
				<&iomuxc_gpio_emc_28_lpspi1_sdo>,
				<&iomuxc_gpio_emc_12_gpio4_io12>;
			drive-strength = "r0-7";
			slew-rate = "fast";
			nxp,speed = "100-mhz";
			bias-pull-up-value = "47k";
		};
	};

[DerekSnell]

Hi @ofirshe ,
You can use any SPI pins supported on the board. I shared the DTS snippet above just as a reference how to configure the devicetree. Feel free to use the pins that work best for you on a board. The same chip select pin used by the SPI peripheral can also be controlled using the GPIO method, so you do not need to change that pin if using the cs-gpios property. Best regards

[ofirshe]

Hey @DerekSnell,

Here's my final configuration that works with the RT1060EVKB:

pinmux_lpspi1: pinmux_lpspi1 {
    phandle = <0x14e>;
    group0 {
        pinmux = <&iomuxc_gpio_sd_b0_01_lpspi1_pcs0>, 
                 <&iomuxc_gpio_sd_b0_00_lpspi1_sck>, 
                 <&iomuxc_gpio_sd_b0_03_lpspi1_sdi>, 
                 <&iomuxc_gpio_sd_b0_02_lpspi1_sdo>;
        drive-strength = "r0-6";
        slew-rate = "slow";
        nxp,speed = "100-mhz";
    };
};

&lpspi1 {
    status = "okay";
    pinctrl-0 = <&pinmux_lpspi1>;
    pinctrl-names = "default";
    cs-gpios = <&gpio3 13 GPIO_ACTIVE_LOW>;

    si5403: spi-dev-si5403@0 {
        compatible = "skyworks,si5403";
        status = "okay";
        spi-max-frequency = <1000000>;
        reg = <0>;
    };
};

I set cs-gpios = <&gpio3 13 GPIO_ACTIVE_LOW> because in the device tree, iomuxc_gpio_sd_b0_01_gpio3_io13 corresponds to iomuxc_gpio_sd_b0_01_lpspi1_pcs0.

From the signal analyzer, I can confirm the clock is running as expected at 1 MHz, and the Chip Select (CS) is now behaving clearly during transactions. However, there's an issue with the data being sent from the controller. I’m sending {0xD0, 0x00}, as shown in my code snippet above, but the MOSI channel in the analyzer shows incorrect data. Could you suggest what might be causing this?

[DerekSnell]

Hi @ofirshe ,

First, I notice that your tx_buf and rx_buf are using the same buffer check_for_CTS_request. That is probably not the cause of your issue here, but I would rule that out and test with separate buffers.

Are you using DMA with this driver? And if so, is this buffer in cacheable memory? If so there could be a coherency issue here where the CPU is initializing your buffer in the cache, but the DMA reads from the physical memory.

You can refer to the working example as a reference and compare with your app. We use the spi_loopback test, and you can run that on this board and compare. That test is also a reference for declaring the buffers in non-cacheable memory to use with the DMA.

Let us know what you find.

[ofirshe]

Hey @DerekSnell,

I compared my configuration with the one found here mimxrt1060_evk.conf. I noticed that, like in the test, I haven't enabled CONFIG_SPI_ASYNC. However, I’m not using CONFIG_SPI_MCUX_LPSPI_DMA, whereas the test configuration does utilize DMA mode.
Given that, I have a few points:

1. Should the spi_mcux_lpspi.c driver work in both modes ? Has it been tested in Zephyr for both configurations?
2. Which mode is preferred in terms of performance measurement ?
3. When I set these three configuration: CONFIG_NOCACHE_MEMORY=y, CONFIG_SPI_MCUX_LPSPI_DMA=y and CONFIG_SPI_ASYNC=n
   I still observe incorrect data, and the CS line appears corrupted. Furthermore, I encountered this compilation warning:

C:/Users/ofirs/bsp/zephyr/drivers/spi/spi_mcux_lpspi.c:298:13: warning: 'spi_mcux_dma_callback' defined but not used [-Wunused-function]
  298 | static void spi_mcux_dma_callback(const struct device *dev, void *arg,

[DerekSnell]

Hi @ofirshe ,

Should the spi_mcux_lpspi.c driver work in both modes ? Has it been tested in Zephyr for both configurations?

There is a known issue with the SPI Async API and the LPSPI driver, see Issue #74907. I have been working on this issue, and just submitted this PR #78194 to enable Async mode with that driver. You are welcome to test it out and add your feedback to the PR.

The spi_loopback test is currently used to test the LPSPI driver, and CONFIG_SPI_MCUX_LPSPI_DMA=y is selected to use the DMA.

Which mode is preferred in terms of performance measurement ?

DMA typically improves performance, especially for longer transfers. The Async APIs allow the calling thread to work other tasks and get notified when the transfer completes.

When I set these three configuration: CONFIG_NOCACHE_MEMORY=y, CONFIG_SPI_MCUX_LPSPI_DMA=y and CONFIG_SPI_ASYNC=n
I still observe incorrect data, and the CS line appears corrupted.

Based on your more recent comment, it appears you see your tx_buf transmitting on the bus now.

Furthermore, I encountered this compilation warning:
C:/Users/ofirs/bsp/zephyr/drivers/spi/spi_mcux_lpspi.c:298:13: warning: 'spi_mcux_dma_callback' defined but not used [-Wunused-function]

The spi_loopback test builds with the same KConfig settings CONFIG_NOCACHE_MEMORY=y, CONFIG_SPI_MCUX_LPSPI_DMA=y and CONFIG_SPI_ASYNC=n, and I do not see this warning. You can see in spi_mcux_lpspi.c, if CONFIG_SPI_MCUX_LPSPI_DMA=y and the DMA channels are enabled, spi_mcux_dma_callback() is used.

Best regards

[ofirshe]

Hey @DerekSnell

By the way, I’ve noticed a potential mismatch between the RT1060EVKB schematics and the LPSPI1 pinout declaration in Zephyr.

In both the RT1060EVKB and RT1060EVK schematics, the SPI MISO (SDO) pin is connected to GPIO_SD_B0_03, and the SPI MOSI (SDI) is connected to GPIO_SD_B0_02.

RT1060EVKB schematics:

RT1060EVK schematics:

However, in Zephyr, these appear to be swapped. Specifically, the Zephyr configuration shows iomuxc_gpio_sd_b0_03_lpspi1_sdi (SDI connected to GPIO_SD_B0_03) and iomuxc_gpio_sd_b0_02_lpspi1_sdo (SDO connected to GPIO_SD_B0_02), which is opposite to what the schematics indicate.

[DerekSnell]

Hi @ofirshe ,
I understand the confusion. The Zephyr pinctrl settings are correct. As the Reference Manual documents, the signal LPSPI1_SDO (SOUT) is on GPIO_SD_B0_02, and LPSPI1_SDI (SIN) is on GPIO_SD_B0_03.

It's not that important with the LPSPI peripheral, because it can also use the SDO signal as the input, ans SDI signal as the output. The schematic labels you see that include MOSI and MISO are the labels for the Arduino header J17 or J24.

Best regards

[ofirshe]

Hey @DerekSnell,

I’ve observed a consistent glitch in the clock signal on the 8th rising edge using a digital analyzer, which causes the corresponding bit to be corrupted. For instance, when sending 0xD0, the last bit of the first byte is transmitted as 1 instead of 0. This glitch is problematic and appears to be deterministic, as it occurs at the same point in the clock cycle for every piece of data I send, leading to corrupted data.

Another instance is when I sent { 0xAA, 0xAA }, and again, the glitch in the clock led to data corruption.

Is there any way to resolve this issue?

[DerekSnell]

Hi @ofirshe ,
Using the test spi_loopback, I see similar waveforms with a narrow clock pulse. However, this does not appear to be a glitch to me. Even with those narrow pulses, the spi_loopback test passes, and my SPI analyzer shows the correct data on the bus.

That narrow clock pulse is related to the last bit in the SPI transfer, as the chip select is deasserted. These first captures show the signals from the spi_loopback test, the 2nd image zoomed in on when the CS deasserts with the narrow pulse.

Then I modified the spi_loopback test to use GPIO for the CS instead of the hardware signal. This shows the GPIO CS is asserted much longer throughout the transfer. But there is still a narrow clock pulse at the end of each byte when the HW CS is deasserted.

If your peripheral device is struggling with this timing, you can configure the timing of the LPSPI. Below are snippets from the RT1060 Reference Manual which detail the timing parameters. Have you already tried configuring these?

Best regards

[ofirshe]

Hey @DerekSnell,

The narrow clock pulse every 8 bits is causing significant issues because all the peripheral devices we’re working with require a duty cycle between 40% and 60% (with 50% being ideal for stable communication). This narrow pulse is disrupting the expected behavior. How can I address and fix this issue to ensure a consistent duty cycle throughout the entire transaction, ideally maintaining 50% like it is during the other clock cycles ?

Thanks.

[DerekSnell]

Hi @ofirshe ,
As I shared before, you need to configure the timing parameters of the LPSPI for your needs. I created the attached project that transmits the 4 bytes you shared. In the capture below, you can see changing an LPSPI timing parameter increased the pulse widths at the end of the frame, and the clock pulses during the transfer are more consistent.

Above in this thread I shared snippets from the Reference Manual about these timing parameters. In Zephyr, these parameters are configured in the devicetree. The LPSPI bindings document these properties. In the attached project, I set transfer-delay to 500 ns with the overlay below to produce the timing waveform above.

&lpspi1 {
	transfer-delay = <500>;
};

The attached project LPSPI_example.zip was configured for and tested on the MIMXRT1170-EVK board. This is also using the hardware chip select, not the GPIO option, although that should not impact the clock pulse timing.

Best regards

[ofirshe]

Hey @DerekSnell,

Thank you for your solution—it successfully resolved the duty cycle issue. At the start of our discussion, you mentioned that the driver might not keep the chip select asserted for the entire duration of the Zephyr SPI transfer. My question is whether NXP plans to address this in a future update to the driver, so that chip select handling will be managed directly at the driver level, rather than relying on the device tree's cs-gpios property.

Best regards,
Ofir.

[DerekSnell]

Hi @ofirshe ,
Yes, NXP is currently improving the LPSPI driver, see #78732

[ofirshe]

Hey @DerekSnell,

@decsny mentioned in that PR that “Note that this does NOT fix the native chip select non-DMA path of the driver”. When the non-DMA path (the mode I use) will be handled ?

Thanks.

[decsny]

@ofirshe do you have a use case for not using the DMA ?

[ofirshe]

Hey @decsny,

Since my transfers are quite small, I understand that DMA is more crucial for larger transactions. Is there any specific reason I should use DMA mode (apart from the fact that it allows for asynchronous transfers)? Which mode would you recommend for my use case?

Thanks.

[decsny]

I am not recommending a mode, I am trying to understand the use case for why someone would not want to use DMA, to know how important is the non-DMA path to support and maintain.

One thing to keep in mind in general, is that OS devs like myself don't always know exactly what's the needs and use cases of the application devs for different things, as the application space is potentially infinitely broad, so your input is important here.