NXP FlexComm LPSPI Problems - FRDM-MCXN947

[ECleverito]

I am looking to use the LPSPI modules available on the MCXN947's FlexComms, but I am unable to see any activity from the controllers when I attempt to write to them. I initially desired to use the LPSPI on FC6 in order to use a Mikroe Clickboard on the MikroBus slot. I added entries for this FlexComm module to my existing overlay:

/ {
	aliases{
		mikroe-slot-i2c = &flexcomm3_lpi2c3;
		mikroe-slot-spi = &flexcomm6_lpspi6;
		j2-spi = &flexcomm1_lpspi1;
	};
};

&pinctrl {

	pinmux_flexcomm3_lpi2c: pinmux_flexcomm3_lpi2c {
		group0 {
			pinmux = <FC3_P0_PIO1_0>,
				<FC3_P1_PIO1_1>;
			slew-rate = "fast";
			drive-strength = "low";
			input-enable;
			bias-pull-up;
			drive-open-drain;
		};
	};

	pinmux_flexcomm6_lpspi: pinmux_flexcomm6_lpspi {
		group0 {
			pinmux = <FC6_P1_PIO3_21>,
				<FC6_P2_PIO3_22>,
				<FC6_P0_PIO3_20>;
			slew-rate = "fast";
			drive-strength = "low";
			input-enable;
		};
	};

};

&peripheral
{
    flexcomm3: flexcomm@95000 {
        status = "okay";
        flexcomm3_lpi2c3: lpi2c@95800 {
            status = "okay";    
            pinctrl-0 = <&pinmux_flexcomm3_lpi2c>;
            pinctrl-names = "default";
			clock-frequency = <I2C_BITRATE_STANDARD>;
        };        
    };
    flexcomm6: flexcomm@b6000 {
        status = "okay";
        flexcomm6_lpspi6: spi@b6000 {
            status = "okay";    
	    cs-gpios = <&gpio3 23 GPIO_ACTIVE_LOW>;
            pinctrl-0 = <&pinmux_flexcomm6_lpspi>;
            pinctrl-names = "default";
			transfer-delay = <1000>;
			eInkDisp: eInkDisp@0 {
				compatible = "vnd,spi-device";
				status = "okay";
				reg = <0>;
				spi-max-frequency = <100000>;
				label = "eInkDisp";
			};
           };
    };
};
&flexcomm3 {
	status = "okay";
};

&flexcomm3_lpi2c3 {
	status = "okay";
};

&flexcomm6 {
	status = "okay";
};

&flexcomm6_lpspi6 {
	status = "okay";
};

I mainly followed the example in the frdm_mcxn947_mcxn947_cpu0.dtsi overlay, as support for LPSPI was added for this board earlier in this commit. The resulting zephyr.dts shows flexomm6_lpspi as "okay" and I am able to retrieve a node ID with the DEVICE_DT_GET() macro and a spi_dt_spec using SPI_DT_SPEC_GET(). To test writing to this device with the zephyr APIs, I have tried manually creating the spi_dt_spec with the node_id:

#define SPI_DEVICE_NODE DT_ALIAS(mikroe_slot_spi)

const struct device *const spi_dev = DEVICE_DT_GET(SPI_DEVICE_NODE);

struct spi_config my_spi_cfg;

int init_spi_device()
{
	my_spi_cfg.frequency = 100000;
	my_spi_cfg.operation = PERVASIVE_E_INK_SPI_OPS_CFG;
	my_spi_cfg.slave = 0;

	if (!device_is_ready(spi_dev))
    {
		LOG_ERR("SPI device not ready.");
		return -1;
	}    

	char str_to_send[] = "Hello World";
	struct spi_buf hello_world_buf;
	hello_world_buf.buf = str_to_send;
	hello_world_buf.len = sizeof(str_to_send);

	struct spi_buf_set hello_world_buf_set;
	hello_world_buf_set.buffers = &hello_world_buf;
	hello_world_buf_set.count = 1;

	int ret = spi_write(spi_dev, &my_spi_cfg, &hello_world_buf_set);
	if(ret < 0)
    {
		LOG_ERR("spi_write error: %d", ret);
		return -1;
	}    	

    return 0;
}

This however, results in the following runtime error:

[00:00:00.005,000] <err> spi_mcux_lpspi: Transfer could not start on spi@b6000: 4
[00:00:00.013,000] <err> e_ink_log: spi_write error: -22

This error is returned at the end of spi_mcux_transfer_next_packet() in the spi_mcux_lpspi.c driver file:

	status = LPSPI_MasterTransferNonBlocking(base, &data->handle, &transfer);
	if (status != kStatus_Success) {
		LOG_ERR("Transfer could not start on %s: %d", dev->name, status);
		return status == kStatus_LPSPI_Busy ? -EBUSY : -EINVAL;
	}

I find it strange that the ...NonBlocking() API is called since I do not have CONFIG_SPI_ASYNC set. Overall, I would like to know if there is anything glaring missing from my overlay device definitions. I have played with the "spi-max-frequency" property by lowering it as well as the spi_config frequency, as I have seen that this caused some troubles in other threads discussing LPSPI. Even at 100 kHz, I am still not seeing successful writes or any activity on the bus. I have tried this with LPSPI1 on FC1 as well, the default lpspi in the overlay, to no avail.

Additionally, here are the contents of my application-specific configuration file:

#Configurer Zephyr drivers
CONFIG_GPIO=y

CONFIG_SERIAL=y
CONFIG_UART_INTERRUPT_DRIVEN=y

CONFIG_I2C=y
CONFIG_SPI=y

CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=y

CONFIG_LOG=y

# Use level below to change level of log messages to filter:
# (O=OFF; 1=ERR; 2=WRN; 3=INF; 4=DBG)
CONFIG_LOG_MAX_LEVEL=1
CONFIG_LOG_DEFAULT_LEVEL=4

CONFIG_STDOUT_CONSOLE=y
CONFIG_LOG_BACKEND_UART=y
CONFIG_LOG_MODE_IMMEDIATE=y

I would like to add that I did learn that clock gating is performed in the board.c, which I have already modified to send the clock to FlexComm6:

#if DT_NODE_HAS_STATUS_OKAY(DT_NODELABEL(flexcomm6))
	CLOCK_SetClkDiv(kCLOCK_DivFlexcom6Clk, 1u);
	CLOCK_AttachClk(kFRO12M_to_FLEXCOMM6);
#endif

What would be the proper way to send this clock without modifying the zephyr source?

[ECleverito]

Tagging for visibility:

@mmahadevan108 I noticed you added the definition of flexcomm1_lpspi1 to the FRDM-MCXN947's base overlay. Were you able to utilize the LPSPI successfully?

@danieldegrasse I sent you an email earlier and you suggested moving this discussion to GitHub

@DerekSnell I have seen you commenting on related threads where you mentioned that work has been underway on the spi_mcux_plspi driver

[DerekSnell]

Hi @ECleverito ,
To debug your app, you found LPSPI_MasterTransferNonBlocking()` returns an error. It would help if you use a debugger and step through that function to find what error it returns and why. That should help narrow down the root cause.

It would also help if you can capture the SPI bus signals during this transfer, so we can see if 4 SPI signals are wiggling as expected.

The spi_loopback test runs and passes on this FRDM-MCXN947 board. You can run that test on the board to compare the differences with your app. Note that for the test to pass, the MOSI and MISO signals must be shorted together externally.

Let us know what you find. Best regards

[ECleverito]

Hi @DerekSnell - thank you for getting back to me.

After tracing with a debugger, I have been able to determine that the error in LPSPI_MasterTransferNonBlocking() is occurring in the call to 'LPSPI_CheckTransferArgument()':

status_t LPSPI_MasterTransferNonBlocking(LPSPI_Type *base, lpspi_master_handle_t *handle, lpspi_transfer_t *transfer)
{
    assert(handle != NULL);
    assert(transfer != NULL);

    /* Check that we're not busy.*/
    if (handle->state == (uint8_t)kLPSPI_Busy)
    {
        return kStatus_LPSPI_Busy;
    }

    LPSPI_Enable(base, false);
    /* Check arguements */
    if (!LPSPI_CheckTransferArgument(base, transfer, false))
    {
        return kStatus_InvalidArgument;
    }

I'm not sure why this returns the error code 4, but after dropping into 'LPSPI_CheckTransferArgument()', I have determined that false if being returned in this function at at the last 'return false' statement in the following code snippet:

    /*The transfer data size should be integer multiples of bytesPerFrame if bytesPerFrame is less than or equal to 4 .
     *For bytesPerFrame greater than 4 situation:
     *the transfer data size should be equal to bytesPerFrame if the bytesPerFrame is not integer multiples of 4 ,
     *otherwise , the transfer data size can be integer multiples of bytesPerFrame.
     */
    if (bytesPerFrame <= 4U)
    {
        if ((transfer->dataSize % bytesPerFrame) != 0U)
        {
            return false;
        }
    }
    else
    {
        if ((bytesPerFrame % 4U) != 0U)
        {
            if (transfer->dataSize != bytesPerFrame)
            {
                return false;
            }
        }
        else
        {
            if ((transfer->dataSize % bytesPerFrame) != 0U)
            {
                return false;
            }
        }
    }

I'm a little puzzled, as none of my overlay's properties are dictating transfer data size or frame size, and I am also following the spi loopback test example much more closely to no avail.

I have indeed set up a logic analyzer on these pins but have yet to see any activity. It is good to hear that those loopback tests have passed on your boards though and I will give them a shot on my own. Just wanted to make sure the LPSPI on Flexcomms has been shown to work on your end mainly.

[ECleverito]

Hi @DerekSnell

I actually resolved my problem after some more investigation. I forgot to add a frame size spi config option. Thanks for checking on this again.

BR
Erich

[DerekSnell]

Hi @ECleverito ,

What would be the proper way to send this clock without modifying the zephyr source?

I run into this sometimes. One option is to add your own SYS_INIT function to the Zephyr startup code. This is code I used recently to enable the same Flexcomm6 clock:

static int app_mcxn947_init(void)
{
	CLOCK_SetClkDiv(kCLOCK_DivFlexcom6Clk, 1u);
	CLOCK_AttachClk(kFRO12M_to_FLEXCOMM6);

	return 0;
}

#if CONFIG_APP_SOC_INIT_PRIORITY <= CONFIG_BOARD_INIT_PRIORITY
	#error CONFIG_APP_SOC_INIT_PRIORITY must be greater than CONFIG_BOARD_INIT_PRIORITY
#endif

SYS_INIT(app_mcxn947_init, PRE_KERNEL_1, CONFIG_APP_SOC_INIT_PRIORITY);

For the Init Priority, you want this early in the startup code before the drivers are initialized, but after the SOC clocks are initialized. I used priority 2 for this.

config APP_SOC_INIT_PRIORITY
	int
	default 2
	prompt "Priority for extra SOC init.  Must be after CONFIG_BOARD_INIT_PRIORITY"