SPI controller performance issue

Stathis,

How are you verifying the delay is 7 SPI clock cycles? Also have you tried to verify whether its 7 SPI cycles always, even with lower SPI clock? Is it constant time or constant number of cycles?

Please see the code below:

    /* Do transfer */
    pRegs->chan[txfer->chan].CTRL = SPI_CHCTRL_EN;
    for (i = 0; i < txfer->size; i++)
      {
          while (!(pRegs->chan[txfer->chan].STAT & SPI_CHSTAT_TX_EMPTY)) ;       
 pRegs->chan[txfer->chan].TX = txfer->tx_buf[i];       
 while (!(pRegs->chan[txfer->chan].STAT & SPI_CHSTAT_RX_FULL)) ;       
 txfer->rx_buf[i] = pRegs->chan[txfer->chan].RX & drivers[fd].data_mask;    
  } 

The first plot here is a poll'd transfer on the SPI bus using the code above.

This plot is the same transfer with the wait on the RX flag removed.

The delay appears to be asynchronous.

Thanks

Cannot see your pictures, but is there any chance you're getting an interrupt when the data finishes, and that's taking the time?

Stathis,

Can you dump the following SPI controller registers which is applicable for your particular channel(fd)?

MCSPI_SYST
MCSPI_MODULCTRL
MCSPI_CH0CONF
MCSPI_CH0STAT
MCSPI_CH0CTRL
MCSPI_XFERLEVEL

Also, did you get a chance to see whether the delay is same 7 cycles with different SPI clocks?

SSorry for the delay I was away. So we played some more...

HHere is a dump of the registers

MCSPI_SYST:       0x00000000
MCSPI_MODULCTRL:  0x00000000
MCSPI_CH0CONF:    0x000103d8
MCSPI_CH0STAT:    0x00000002
MCSPI_CH0CTRL:    0x00000000
MCSPI_XFERLEVEL:  0x00000000
WRITING BYTES:
MCSPI_SYST:       0x00000000
MCSPI_MODULCTRL:  0x00000001
MCSPI_CH0CONF:    0x001103d8
MCSPI_CH0STAT:    0x00000002
MCSPI_CH0CTRL:    0x00000000
MCSPI_XFERLEVEL:  0x00000000
XFER COMPLETE:
MCSPI_SYST:       0x00000000
MCSPI_MODULCTRL:  0x00000000
MCSPI_CH0CONF:    0x000103d8
MCSPI_CH0STAT:    0x00000006
MCSPI_CH0CTRL:    0x00000000
MCSPI_XFERLEVEL:  0x00000000

 
 I have concerns with delays inbeteen SPI frames and the delay between the transmition of the last bit and the assertion of the "RX_READY" flag.

 1) There are gaps of 2.25 clock cycles between SPI frames.

 2) When in "force" mode there is a fixed delay following the transfer that seems to be asynchronous (SPI clock frequency independent). 
 In poll'd mode, that time is on the order of 1uS (1MHz).  When using DMA, this delay gets a bit worse when we wait on the last RX DMA event to fire.
 At higher  frequencies, the delay between the final clock and the chip select deassertion becomes proportionately large; it is 4 clocks time at 4MHz! 
When running at 10+MHz, this delay becomes a huge overhead (unfortunately my logic analyzer is limited to 8MHz sampling).

Stathis,

Can you try setting these bits in MCSPI_CH0CONF registers and see any change in behavior?

1. Turbo mode
2. FFEW
3. FFER

Also check the section in the TRM "24.3.2.6.3 Turbo Mode"