DMA/SPI clock behavior on MIMXRT1024-EVK using LPSPI

[vibai-aspade]

Hi all,

I’m working on an application using the LPSPI peripheral on the mimxrt1024_evk board, and while I’ve got basic SPI communication working, I’m running into a strange issue I can’t quite figure out.

The actual SPI transaction looks fine and is pretty short, but I’m noticing that the last clock bit seems to be held high for longer than expected at least 15+ microseconds than needed. I suspect this is related to the DMA engine that the LPSPI driver is using under the hood, or maybe just some overhead from the driver itself. I’m not sure.

I’m also seeing some odd behavior at higher SPI frequencies (20 MHz+) where the 8th clock bit stays high and the transmission kind of breaks down.

I’m new to Zephyr, so it’s very possible I’m missing something obvious in my prj.conf or overlay setup. Has anyone seen this kind of thing before? Any ideas on what might be causing that clock line to hang, or how to reduce that delay at the end of the transaction?

Here are some screenshots I captured on my logic analyzer:
SPI Capture at 10 MHz:

SPI Capture at 30 MHz

[Raymond0225]

hi @vibai-aspade ,
thank you for your information.
may I know what APIs you are calling in your application. i assume that RT1024 is working on master SPI mode, right?
I would like to replicate this issue on my side, if you could provide some source code of the testing, it will be better.

[vibai-aspade]

Hi @Raymond0225,

I’ve attached my code and board overlay below. Yesterday, I ran a loop back test and checked the signals on the oscilloscope and the chip select assertion looks clean, which is good. However, I did notice some clock glitches between transfers. It’s not affecting my current application, but it might be an issue later on.

Based on the loop back test it doesn’t appear to be a problem with the Zephyr SPI drivers. I suspect the issue lies in how I’m structuring or sending the data during transfers. I also did a comparison between the zephyr.dts and .config files between the loopback test and my code and everything seems to match on that end.

My code:

#include <zephyr/drivers/spi.h>
#include <zephyr/kernel.h>
#include <zephyr/logging/log.h>
#include <zephyr/cache.h>
#include <zephyr/drivers/gpio.h>
#include <zephyr/devicetree.h>

LOG_MODULE_REGISTER(AD4021_TEST);

static const struct device *spi_dev = DEVICE_DT_GET(DT_NODELABEL(lpspi1));

static struct spi_config spi_cfg = {
    .frequency = 10000000, 
    .operation = SPI_OP_MODE_MASTER | SPI_TRANSFER_MSB | SPI_WORD_SET(8), 
    .slave = 0,
};

__attribute__((__section__(".nocache"))) __aligned(32) static uint8_t read_tx[4] = {0x54, 0xFF, 0x00, 0x00}; 
__attribute__((__section__(".nocache"))) __aligned(32) static uint8_t write_tx[4] = {0x14, 0x12, 0x00, 0x00};

__attribute__((__section__(".nocache"))) __aligned(32) static uint8_t rx[4];

void readConfig(){
    const struct spi_buf write_tx_buf = {.buf = write_tx, .len = 4};
    const struct spi_buf read_tx_buf = {.buf = read_tx, .len = 4};
    const struct spi_buf rx_buf = {.buf = rx, .len = 4};
    struct spi_buf_set write_tx_set = {.buffers = &write_tx_buf, .count = 1};
    struct spi_buf_set read_tx_set = {.buffers = &read_tx_buf, .count = 1};
    struct spi_buf_set rx_set = {.buffers = &rx_buf, .count = 1};

    spi_transceive(spi_dev, &spi_cfg, &write_tx_set, &rx_set);
    spi_transceive(spi_dev, &spi_cfg, &read_tx_set, &rx_set);
    spi_transceive(spi_dev, &spi_cfg, &write_tx_set, &rx_set);
    spi_transceive(spi_dev, &spi_cfg, &read_tx_set, &rx_set); 
    spi_transceive(spi_dev, &spi_cfg, &write_tx_set, &rx_set);
    spi_transceive(spi_dev, &spi_cfg, &read_tx_set, &rx_set); 

}
int main(void) {
    LOG_INF("=== SPI Controller Diagnostics ===");
    if (!device_is_ready(spi_dev)) {
        LOG_ERR("SPI device not ready - check devicetree configuration");
        return -1;
    }
	readConfig();

    return 0;
}

Overlay

&lpspi1 {
    transfer-delay = <50>;
    pinctrl-0 = <&pinmux_lpspi1>;
    pcs-sck-delay = <30>;
};

&pinmux_lpspi1 {
    group0 {
        pinmux = <&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 = "fast";
        nxp,speed = "100-mhz";
    };
};

[Raymond0225]

hi @vibai-aspade,
when it comes to the 1st picture you captured, I beileive it is normal. we can see there are 6 transfers in your picture and for each transfer, there is a period of "blank"(no clock, no data). This period can be long, can be short. it is because there are IP limitations for RT10xx platform: a TCR command has to be issued after the last TX transfer or RX will never end. As this TCR command is issued inside DMA ISR, it may issue immediately after transfer, or a little bit later depend on OS scheduling and code is cached or not. you can have a look at function: spi_mcux_issue_TCR() in detail.
I also tried to run your code inside a loopback test function and got below picture, you can see after each transfer, there is a "tail".

a transfer "tail" of 21.42us:

for the "tail" after each frame(8 clocks in your case), it is configurable.
transfer-delay = <100>; // it means a 100ns delay between frames.
generally, it should be set as half of clock period to make clock looks continuously. for example, for 10MHz, 50 is suggested.

let me know if you have more questions.