Eliminating big gaps in SPI transmission

[chrispflieger]

I'm seeing big gaps (5 us) between each byte in the transmission. What's the cause and how do I fix it?

Here's my init and transfer function, I'm using the latest CMSIS LPCOpen code. I pretty much lifted this from the example. I'm controlling the CS manually.

void int(void)
{
    SPI_CFGSETUP_T spiSetup;
    SPIM_DELAY_CONFIG_T masterDelay;

    /* Initialize SPI controller */
    Chip_SPI_Init(EVE_SPI);    /* Call to initialize first SPI controller for mode0, master mode, MSB first */
    Chip_SPI_Enable(EVE_SPI);
    spiSetup.master = 1;
    spiSetup.lsbFirst = 0;
    spiSetup.mode = SPI_CLOCK_MODE0;
    Chip_SPI_ConfigureSPI(EVE_SPI, &spiSetup);
    /* Setup master controller SSELx for active low select */
    Chip_SPI_SetCSPolLow(EVE_SPI, EVE_SSEL);
    /* Setup master clock rate, but start off slow. */
    Chip_SPIM_SetClockRate(EVE_SPI, 1000000);
    /* Setup master delay (all chip selects) */
    masterDelay.PreDelay = 0x00;
    masterDelay.PostDelay = 0x00;
    masterDelay.FrameDelay = 0x00;      // This can be as low as zero, but set to two to making debugging easier w/ a scope.
    masterDelay.TransferDelay = 0x01;   // The minimum is 1.
    Chip_SPIM_DelayConfig(EVE_SPI, &masterDelay);
}



    /* Setup master transfer callbacks in the transfer descriptor */
    spiMasterXfer.eventCB = NULL;

static void spi_transfer(uint8_t *data, size_t size)
{
    /* Set up master transfer block */
    spiMasterXfer.txData = data;                        /* set master transmit pointer      */
    spiMasterXfer.txCount = size;                       /* set master transmit frame count  */
    spiMasterXfer.rxData = data;                        /* set master receive pointer       */
    spiMasterXfer.rxCount = size;                       /* set master receive frame count   */
    spiMasterXfer.dataWidth = 8;
    spiMasterXfer.sselNum = 0;                          /* set SPI select                   */
    spiMasterXfer.txIndex = 0;                          /* clear the transmit buffer index  */
    spiMasterXfer.rxIndex = 0;                          /* clear the receive buffer index   */
    spiMasterXfer.option = 0;
    Chip_SPIM_XferBlocking(EVE_SPI, &spiMasterXfer);
}

[chrispflieger]

I made these changes:

Using Chip_SPIM_XferFIFO() instead of interrupts and changing optimization to -Os, brought the byte time to 1 us. (a 5x speed increase!) So, I realize that almost all the gap I saw was related to the the driver's overhead and function calls.

These times are acceptable, and I'll be implementing a DMA driver for large data transfers.

I think Chip_SPIM_XferFIFO() has a bug or two.

When I pass in rxCount = 0, and rxData = NULL, the driver gets stuck on this line:

while (SPI_FIFOSTAT_RXLVL(Chip_SPI_GetFIFOStatus(pSPI)) < xfer->rxCount);

If I pass in an rxData buffer and rxCount < txCount, I get a buffer overrrun.

[kerryzhou · Accepted solution]

Hi Chris,

    Yes, you are right.

     If you call another SPI frame,  a lot of functions will be called again, so the big gap between the two frames(not between bytes in the same frame) is long, the SPI code is really a little redundancy, so if you very care about the execution time, I think you can simplify the SPI function, you can design it by yourself, don't use too many function calls.

If you don't want to receive the the SPI data, I think you can delete the receive code, it will save the code execution time.

Wish it helps you!

Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[chrispflieger]

I checked by switching to IRQ based operation, no change. I tried other clock speeds, 12 MHz is the fastest, but setting it to 5 MHz gives me a true 5 MHz clock speed. Most everything else is working OK, including the USB MSC demo.

[kerryzhou]

Hi Chris,

   Please give me the sample code package name, I will help you to test, and check it on my side when I have time.

Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[chrispflieger]

Kerry, did you get that code package I emailed? I still have this problem, but haven't spent any time on it.

[kerryzhou]

Hi Chris,

  Sorry for my later reply, I have got your code.

 I have test the periph_spi_sm_poll project, this is the SPI bus:

The time is just 640 ns between bytes, it's not long.

Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[chrispflieger]

Here's what I see. D0 is the clock - which each little burst is one byte. D1 is data, D3 is CS.

D6 is a debug pin set inside Chip_SPIM_XferHandler(), which shows that during the seven byte sequence it never exits that ISR and is just running as fast as it can.

This doesn't make much sense - each loop to process a byte is taking 5 us. Should the CPU be able to process it faster than that? I set the clkout to the main clock - it's 94 MHz.

[chrispflieger]

Hmm. What is the clock frequency on that capture?

[kerryzhou]

Hi Chris Pflieger,

   The SPI clock baudrate is 4Mhz.

Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[chrispflieger]

MCPXpresso v10.0.0.2

LPC54113J256

How would I know what LPCopen version I'm using? I downloaded it within the current year...

Is it possible this is a clock issue? I'm trying to get to 30 MHz, Chip_SPIM_SetClockRate(SPI, 25); but it tops out at 12 MHz.

I pulled the code from "periph_spi_sm_poll" into my project.

[kerryzhou]

Hi Chris,

    Please tell me where you download the code.

   You can give me the code package name, eg:

Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[chrispflieger]

https://www.nxp.com/support/developer-resources/software-development-tools/lpc-developer-resources-/...

I believe I have either the latest – 3.01 or 3.00c.

[kerryzhou]

Hi Chris,

  Please tell me the LPC chip part number, and the what the lpcopen reversion you are using, also tell me your test project, I will check it on my side.

Waiting for your reply!

Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------