@MaureenHelm is this issue being looked at?

@MaureenHelm is this issue being looked at?

Not yet, but going to try to look at it tomorrow.

This is caused by the underlying MCUX SDK LPSPI driver missing a feature to hold the chip select active after a transfer. The underlying MCUX SDK DSPI driver used on frdm_k64f has a kDSPI_MasterActiveAfterTransfer flag that we need in the LPSPI driver used on KE1xF and i.MX RT10xx. I will file an internal NXP ticket to add this feature.

Decreasing the priority of this bug from medium to low since we can work around it with GPIO CS.

This is still an issue with the most recent MCUX SDK (I was just bitten by this issue on bringing up a newly developed board today). Should we change all affected in-tree boards to use cs-gpios until this is resolved?

@henrikbrixandersen i've encountered similar issues with SPI on LPC55xxx, see my 2 pulls:

• Eth Click #26213 using GPIO CS rather than the device's slave select
• LPC55xxx SPI fixes #26371 a fix for SS device remaining low until frame ends, undoes parts of the previous pull

Re-opening after discord discussion, as this issue is still relevant.

If CONFIG_SPI_MCUX_FLEXCOMM_DMA=y, this issue also appears with the spi_mcux_flexcomm driver.

(If CONFIG_SPI_MCUX_FLEXCOMM_DMA is not enabled, then spi_mcux_flexcomm has correct CS behavior regardless of whether GPIO or hardware CS is used.)

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

I produced this code to try to reproduce the issue on mimxrt1024_evk on commit b573f44 based on what was originally posted by @henrikbrixandersen :

#include <zephyr/kernel.h>
#include <stdio.h>
#include <zephyr/drivers/spi.h>
#include <zephyr/drivers/gpio.h>
#include <zephyr/sys/util.h>

struct spi_config spi_cfg = SPI_CONFIG_DT(DT_NODELABEL(dummy_spi_dev),
		(SPI_OP_MODE_MASTER | SPI_TRANSFER_MSB | SPI_WORD_SET(8)), 1);

const struct device *spi_ctlr = DEVICE_DT_GET(DT_NODELABEL(lpspi1));

#define XFER_SIZE 2

uint8_t cmd[XFER_SIZE] = {0xaa, 0x55};
uint8_t resp[XFER_SIZE];

const struct spi_buf tx_bufs[] = {
	{
		.buf = cmd,
		.len = sizeof(cmd),
	},
};

const struct spi_buf_set tx = {
	.buffers = tx_bufs,
	.count = ARRAY_SIZE(tx_bufs),
};

const struct spi_buf rx_bufs[] = {
	{
		.buf = NULL,
		.len = sizeof(cmd),
	},
	{
		.buf = resp,
		.len = sizeof(resp),
	},
};

const struct spi_buf_set rx = {
	.buffers = rx_bufs,
	.count = ARRAY_SIZE(rx_bufs),
};

int main(void)
{
	if (!spi_ctlr) {
		printf("SPI device not found");
		return 1;
	};

	if (!spi_cfg.cs.gpio.port) {
		printf("Using native CS\n");
	} else {
		printf("Using GPIO CS\n");
	}

	spi_transceive(spi_ctlr, &spi_cfg, &tx, &rx);

	printf("Transmission finished.\n");

	return 0;
}

With DT overlay

#include <zephyr/dt-bindings/gpio/gpio.h>
#include <zephyr/dt-bindings/spi/spi.h>

&pinmux_lpspi1 {
		group0 {
			pinmux =
				<&iomuxc_gpio_ad_b0_11_gpio1_io11>,
				<&iomuxc_gpio_ad_b0_10_lpspi1_sck>,
				<&iomuxc_gpio_ad_b0_11_lpspi1_pcs0>,
				<&iomuxc_gpio_ad_b0_12_lpspi1_sdo>,
				<&iomuxc_gpio_ad_b0_13_lpspi1_sdi>;
			drive-strength = "r0-6";
			slew-rate = "slow";
			nxp,speed = "100-mhz";
		};
};

&lpspi1 {
	cs-gpios = <&gpio1 11 GPIO_ACTIVE_LOW>;
	dummy_spi_dev: dummy_spi_dev@0 {
		compatible = "spi-device";
		reg = <0>;
		duplex = <SPI_FULL_DUPLEX>;
		spi-max-frequency = <100000>;
 	};
};

And I observed the behavior to be the same whether or not the cs-gpios property was commented out of the DT or not. The behavior of both versions being that the CS is deasserted between the parts of the transfer.

Please someone who had this issue please confirm if I missed something in this code or if the behavior did indeed change in the last 5 years, or maybe the issue is specific to only some platforms

Please someone who had this issue please confirm if I missed something in this code or if the behavior did indeed change in the last 5 years, or maybe the issue is specific to only some platforms

I can try to reproduce this when I return from Seattle. My original finding was on the twr_ke18f board.