spi_mcux_lpspi - How can I ensure that the Chip Select line remains asserted for the entire transaction

[ofirshe]

Hi,

I've rebased my Zephyr codebase to include the latest fix by @decsny for the LPSPI driver (drivers: spi_mcux_lpspi: Fix DMA path on RT). However, I’m observing similar symptoms in both DMA and non-DMA modes, even when using the cs-gpios workaround (as the CS is currently not working in the non-DMA path).
Here’s the code I’m using for the transaction:

uint8_t tx_data[2] = { 0 };
uint8_t rx_data[4]  = { 0 };
uint16_t rx_len;
uint16_t tx_len;

tx_data[0] = 0xD0;
tx_len = 1;
rx_len = 3;
const struct spi_buf tx_buf = { .buf = tx_data, .len = tx_len };
const struct spi_buf rx_buf = { .buf = rx_data, .len = rx_len };
const struct spi_buf_set tx = { .buffers = &tx_buf, .count = 1 };
const struct spi_buf_set rx = { .buffers = &rx_buf, .count = 1 };
return spi_transceive_dt(&cfg->bus, &tx, &rx);

SPI configured mode: SPI_WORD_SET(8) | SPI_OP_MODE_MASTER | SPI_TRANSFER_MSB

Apart from an issue with the component on the MISO line (which I'm troubleshooting separately), I notice that the CS line does not remain asserted until the device completes its response. This issue occurs in both DMA and non-DMA modes, while I would expect CS to stay asserted for the entire transaction.

Best Regards,
Ofir.

[decsny]

Yes, the PR you linked was a hotfix so that the lpspi dma worked at all on RT, it effectively reverted the previous fix of the CS. Now that fix only applies to the MCXN, since that's actually the platform I was developing on when I made that fix. It turns out the lpspi on RT and MCX work significantly differently in regards to when the receiver writes to the RX fifo

[ofirshe]

@decsny Ok, just notice that now in both DMA and non-DMA modes, even with the cs-gpios workaround in the non-DMA path, I see the same behavior - the CS is being deasserted during the transaction which is undesired.

[ofirshe]

@decsny This issue is very urgent for us, as we’re unable to communicate with external devices over SPI. Are you planning to address it soon, or do you have any workaround we could use in the meantime?

[DerekSnell]

Hi @ofirshe ,
NXP is working on this issue, as you know from the on-going PRs and discussions.

As for workarounds, you have shared in the past that you had the LPSPI functional. Does reverting the driver back to that previous version work for you? Or, you are currently using a GPIO pin to control the chip select. Could you control that GPIO pin from your application instead of from the driver, and keep it asserted through the whole transfer?

Best regards

[ofirshe]

Hi @DerekSnell,

NXP is working on this issue, as you know from the on-going PRs and discussions.

Could you please share the link to this issue and the PR intended to address this specific issue?

I haven’t yet had the LPSPI fully functional. I still haven’t established successful communication with the external device I’m trying to reach. The same symptom was present even before the recent PR by @decsny was merged. As I mentioned, I’m now seeing this behavior consistently on the RT waveforms in both DMA and non-DMA modes. In non-DMA mode, I’m using the cs-gpios workaround you've recommended me , as CS is totally corrupted in non-DMA mode.

BR

[ofirshe]

Hi @DerekSnell,

I added the SPI_HOLD_ON_CS and SPI_LOCK_ON flags to the SPI configuration and called spi_release_dt() after spi_transceive_dt(). However, the CS line is still deasserting during the transaction, showing the same behavior as I sent above.

[ofirshe]

Hi @DerekSnell,

Since controlling the CS line from the application didn’t resolve the issue, is there something else I should try, or should I wait for a fix? It seems like the problem might go beyond just the CS line—despite calling spi_transceive_dt() only once, the RT appears to generate two separate transactions instead of one. Also, you may have missed my previous message; could you direct me to the relevant PR?

Best Regards

[DerekSnell]

Hi @ofirshe ,
The method you describe above is still using the SPI driver to control the GPIO signal as chip select. For the workaround proposal to control the GPIO from your app, I meant using the GPIO driver to control that pin as the chip select, to workaround using the SPI driver.

Best regards

[tbursztyka]

Using GPIO as @DerekSnell will solve the issue.
That said, the driver seems to be doing the right thing, see lines 107-108 where it asks to run in Pcs Continuous, which according to mcux's headex file seem to be about keeping CS asserted after the transfer (unless I misunderstood it). Could be a bug in the HAL then?

[ofirshe]

But @tbursztyka, what I’m saying is that the clock signal isn’t continuous either, which suggests the RT is treating this as two separate transactions rather than one. In each part, the clock and CS appear correct, but the issue seems to be that it’s splitting it into two distinct transactions. I hope I’m not mistaken.

[tbursztyka]

The clock signal is fine, it is generated by the controller only when it emits data. The only thing which is bogus here is the cs line.

[ofirshe]

@tbursztyka @DerekSnell @decsny

This waveform was captured on a Linux OS using the SPIDEV device driver.

• The top yellow trace represents the Chip Select (CS) line.
• The second blue trace shows the clock signal.
• The third red trace corresponds to MOSI.
• The fourth trace displays MISO.

As observed, the CS line is driven low and remains asserted until the entire transaction is complete. During this time, the master continuously generates a clock signal for the entire transaction. This is the expected behavior for the waveform corresponding to the code snippet shared earlier.

How can we proceed from here ?

[tbursztyka]

The clock is totally fine in zephyr's output as well.

In a scatter-gather and asymmetrical buffer set as SPI API has, your driver will need to switch from one buffer to another (tx, rx, or both). Yet, they are all part of a unique transaction, and thus during that time: CS must stay asserted.

See drivers/spi/spi_mcux_lpspi.c:spi_mcux_transfer_next_packet(), due to the HAL, it needs to do some evaluation of buffer size etc...
So the first pass : tx_len (1) < rx_len (3), it will follow the else {}, second pass it will follow the first if (ctx->tx_len == 0) {}.
The delay you have between the first pass and the second one, is due to this driver buffer processing. Clock stopping during that delay, is totally fine. Else: the peripheral would continue to interpret its input line, and it would output something as well, which is not what we want.

In the linux example you show, transaction happens all at once, thus the clock being on the whole time.

The unique problem in your case is the CS line being de-asserted during the delay you observed. It should not happen. That's the bug.
And so far, I don't see any problem in the driver itself (at least in non-dma path which I quickly checked)
To me, this sounds like a HAL issue. (without using cs-gpio - using controller cs line then - it must follow kLPSPI_MasterPcsContinuous which is properly set by the driver: and already if it does not ... that's a HAL issue).

Btw as a workaround: since your transaction is super small, and so you don't really get any significant memory gain in reducing tx buffer vs rx one. Just make both buffers symmetrical.

uint8_t tx_data[4] = { 0 };
uint8_t rx_data[4]  = { 0 };

tx_data[0] = 0xD0;

const struct spi_buf tx_buf = { .buf = tx_data, .len = 4 };
const struct spi_buf rx_buf = { .buf = rx_data, .len = 4 };
const struct spi_buf_set tx = { .buffers = &tx_buf, .count = 1 };
const struct spi_buf_set rx = { .buffers = &rx_buf, .count = 1 };
return spi_transceive_dt(&cfg->bus, &tx, &rx);

That should work, you should see the transaction being done all at once (above driver function will follow } else if (ctx->tx_len == ctx->rx_len) { path). Though it is not a fix for the CS bug you observe, at least you should be able to proceed with other stuff, while NXP guys look at the driver and HAL.

[ofirshe]

Hi @tbursztyka,

Thank you for the workaround! I’m now successfully communicating with the device and receiving reasonable responses.

As you mentioned, for LPSPI to function properly, the cs-gpios property alone is insufficient; the transmit (TX) and receive (RX) buffer sizes must also be equal. This crucial detail might benefit from being added to this thread for clarity.
However, this restriction complicates development, as maintaining equal buffer sizes adds overhead to implementation. @DerekSnell, do you know when NXP plans to prioritize addressing this issue? The driver has been problematic for quite some time, and a fix would be nice.

Best Regards.

[DerekSnell]

Hi @ofirshe and @tbursztyka ,
Ofirshe, I am glad you have a solution that is working for you now. And thank you tbursztyka for suggesting this workaround.

However, I get different results when testing this. With cs-gpios, I see the chip select asserted once for the full transfer, even with unequal buffer sizes. Ofirshe's captures look like my capture when using the hardware chip select signal, without cs-gpios.

I tested with the attached project LPSPI_cs-gpio.zip, which uses your buffer configuration. I tested this with the latest Zephyr release v4.0.0, on the board mimxrt1170_evk//cm7, which uses the same LPSPI driver. Here is the capture using this example, using cs-gpios without DMA. The chip select GPIO is asserted through the full transfer. Enabling the DMA in this example still keeps CS asserted for the full transfer.

When I remove cs-gpios and use the hardware chip select driven by the LPSPI peripheral, I see a waveform similar to yours, with CS deasserting between the 2 hardware transfers. This is related to the known issue originally reported in spi_mcux_lpspi: inconsistent chip select behaviour.

And if I enable DMA with the hardware CS, CS gets an additional pulse.

So my captures seem consistent with the known issues in the LPSPI driver, which NXP resolved on the MCX N platform, and is working to resolve on the RT platforms.

@ofirshe , can you share captures showing the difference between cs-gpios and using the hardware chip select? I also notice in your captures that the CS signal toggles immediately with the CLK signal. But when I use cs-gpios, there is delay between the CS GPIO and the CLK signals. I wonder if your captures are still using the hardware chip select. Thanks

[ofirshe]

Hey @DerekSnell,

My Zephyr is aligned with commit hash c50777a, which includes the most recent change to this driver (92d0287).

I’m currently running in non-DMA mode (only CONFIG_SPI is enabled, and CONFIG_SPI_ASYNC is not set) and using cs-gpios (as referenced here: GitHub Discussion Link). For reference, I’m working with the RT1060EVKB evaluation board.

Here’s what I’ve observed:

When the buffer sizes are not equal, using the same code as in your example, the Chip Select (CS) is deasserted during the transaction.

However, when the buffer sizes are equal, as in this example: GitHub Discussion Link, I get the expected behavior, with the CS remaining asserted.

Let me know if you need further details or clarification.

[DerekSnell]

Yes, @ofirshe

But my request was for you to provide captures with and without using cs-gpios with the unequal buffer sizes. I still suspect your captures are using the hardware chip select, not the GPIO chip select.

Cheers

[ofirshe]

@DerekSnell Have you read @tbursztyka's explanation of the issue here: GitHub Discussion Link?

[tbursztyka]

One thing I forgot to ask @ofirshe, on this:

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

Are you 100% sure that gpio3 line 13 is properly pinmuxed (in the pinmux_lpspi1)? if not, that could perhaps also explain the cs behavior being the same as without cs-gpios: controller's inner cs would be still at play.

[ofirshe]

@tbursztyka 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. I hope I’m not mistaken.

[DerekSnell]

@ofirshe ,

Are you also changing the pinmux setting in the pinctrl to use iomuxc_gpio_sd_b0_01_gpio3_io13 instead of iomuxc_gpio_sd_b0_01_lpspi1_pcs0? If the pinmux is still using iomuxc_gpio_sd_b0_01_lpspi1_pcs0, then the LPSPI hardware is still driving that pin.

I will add more details for the devicetree settings here after a quick confirmation on my board...

[ofirshe]

I checked on the RT1060 board, and this appears to be the default configuration. So, you’re probably correct, @DerekSnell—this line: cs-gpios = <&gpio3 13 GPIO_ACTIVE_LOW>; seems to be meaningless(assuming iomuxc_gpio_sd_b0_01_gpio3_io13 and iomuxc_gpio_sd_b0_01_lpspi1_pcs0 refer to the same GPIO). I’ll try removing this line from the DTS tomorrow and will update you.

[DerekSnell]

@ofirshe , the cs-gpios property is not meaningless. That property configures the Zephyr SPI driver to drive a GPIO signal as the chip select, and also specifies which GPIO signal to drive. But you also need to configure the pinmux setting in the pinctrl node. In your case, the MIMXRT1060-EVK board configures the iomuxc_gpio_sd_b0_01_lpspi1_pcs0 pinmux option for that pin. You are trying to use that same pin, but configure it as GPIO signal instead of the SPI hardware CS signal.

To help clarify, here are details based on the LPSPI_cs-gpio.zip example I attached above. This example was written for the MIMXRT1170-EVK board using LPSPI1. Below is the overlay file to configure LPSPI1 to use the GPIO signal as the chip select with the cs-gpios property. Notice the pinmux property here configures iomuxc_gpio_ad_29_gpio9_io28, which configures the pin GPIO_AD_29 for the GPIO signal, using GPIO port 9 pin 28. These settings give the waveform captured above using the GPIO chip select.

&lpspi1 {
	transfer-delay = <500>;
	cs-gpios = <&gpio9 28 GPIO_ACTIVE_LOW>;
	spi_periph: spi-periph@0 {
		compatible = "vnd,spi-device";
		reg = <0>;
		spi-max-frequency = <1000000>;
	};
};

&pinmux_lpspi1 {
	group0 {
		pinmux = <&iomuxc_gpio_ad_29_gpio9_io28>,
			<&iomuxc_gpio_ad_28_lpspi1_sck>,
			<&iomuxc_gpio_ad_31_lpspi1_sdi>,
			<&iomuxc_gpio_ad_30_lpspi1_sdo>;
		drive-strength = "high";
		slew-rate = "fast";
	};
};

Next I modify the overlay to use the LPSPI hardware CS signal. Remove the cs-gpios property, and change the pinmux setting to iomuxc_gpio_ad_29_lpspi1_pcs0. This setting produces the waveform I shared above with hardware chip select.

&lpspi1 {
	transfer-delay = <500>;
	spi_periph: spi-periph@0 {
		compatible = "vnd,spi-device";
		reg = <0>;
		spi-max-frequency = <1000000>;
	};
};

&pinmux_lpspi1 {
	group0 {
		pinmux = <&iomuxc_gpio_ad_29_lpspi1_pcs0>,
			<&iomuxc_gpio_ad_28_lpspi1_sck>,
			<&iomuxc_gpio_ad_31_lpspi1_sdi>,
			<&iomuxc_gpio_ad_30_lpspi1_sdo>;
		drive-strength = "high";
		slew-rate = "fast";
	};
};

Next I replicate the setting I believe you were using, which is not configured properly for GPIO CS. The cs-gpios node is included. But the pinmux is stil for the hardware CS, not GPIO. This produces the same waveform as using the hardware chip select. I hope this clarifies how to configure using a GPIO as chip select.

&lpspi1 {
	transfer-delay = <500>;
	cs-gpios = <&gpio9 28 GPIO_ACTIVE_LOW>;
	spi_periph: spi-periph@0 {
		compatible = "vnd,spi-device";
		reg = <0>;
		spi-max-frequency = <1000000>;
	};
};

&pinmux_lpspi1 {
	group0 {
		pinmux = <&iomuxc_gpio_ad_29_lpspi1_pcs0>,
			<&iomuxc_gpio_ad_28_lpspi1_sck>,
			<&iomuxc_gpio_ad_31_lpspi1_sdi>,
			<&iomuxc_gpio_ad_30_lpspi1_sdo>;
		drive-strength = "high";
		slew-rate = "fast";
	};

[ofirshe]

@DerekSnell, I understand your clarification, and yes, my case aligns with the third scenario you mentioned. That makes sense because I observed the same waveform when using non-equal buffer sizes. I believe that if you equalize the buffer sizes, the issue will resolve, and you’ll see the same waveforms as with the GPIO CS.

[ofirshe]

Hey @DerekSnell,

I tried this morning to remove the cs-gpios property from the DTS, defaulting to hardware-controlled CS.

When the TX and RX buffer sizes are equal, I observe the expected behavior.

However, with unequal buffer sizes (as in your example), I see the same waveforms you shared earlier.

On your side, try setting equal sizes for the TX and RX buffers—I assume you’ll observe the expected behavior as well.

It seems the NXP HAL or the spi_mcux_lpspi driver doesn’t handle non-equal TX/RX transactions properly with hardware-controlled CS. As you mentioned, using GPIO for chip select probably provides a workaround for this issue.

Everything seems to make sense now, I believe.

Best Regards,
Ofir.

[ofirshe]

Hey @DerekSnell,

Were you able to equalize the buffer sizes on your end? How can we move forward to resolve this issue?

Thanks.

[ofirshe]

Hi @DerekSnell,

Any update ?

[DerekSnell]

Hi @ofirshe ,
You now have multiple workaround options to manage the chip select signal, and have already confirmed you have a working solution. That's great to hear.

As you already know, the LPSPI driver has a known issue keeping the hardware chip select asserted through some transfers, which is tracked at spi_mcux_lpspi: inconsistent chip select behaviour. You can subscribe to that Issue to get updates on the progress. And in the meantime, you can move on using these workarounds.

Best regards