Long ~30uS delay between SPI byte transmissions in fsl_dspi during call to DSPI_DRV_MasterTransferBlocking(), what causes it?

[chadwilliams]

I have been testing an application that writes to an LCD using SPI and have noticed its slow and decided to look into the cause.

Processor MK24FN1M0120VLL

CPU clock 20.97152MHz

SPI clock rate  2.097MHz

SPI intance   DSPI2  ( 1 byte FIFO)

KSDK version 1.2.0 using Processor expert for driver configuration, KDS3.0

the display data is being written in successive calls to :

dspiResult = DSPI_DRV_MasterTransferBlocking(FSL_DSPICOM1,NULL, pagebuf,NULL, bufindex+1, LCD_MASTER_TRANSFER_TIMEOUT);

close inspection of the data being transmitted revealed there is about 32 microseconds delay between each byte

and each byte takes 3.8 microseconds  to transmit.  I want to significantly reduce this 32 uS delay in order to make display refresh activity  not visible to the user.

I have done some digging and found there are programmable delays  and have made a call to adjust the delay after transfer to 476nS

status = DSPI_DRV_MasterSetDelay(instance, kDspiAfterTransfer, 476, & calculatedDelayaftertransfer);

if (status != kStatus_DSPI_Success) return;

but this code returns with kStatus_DSPI_Success but appears to have no effect.

Since its a simple blocking write to SPI from a buffer, the code should write to SPI without significant delays.

Is there anything I should do to eliminate the delay between bytes?

I have attached an image of the master configuration in PE

[Jorge_Gonzalez]

Hello Chad Williams:

We are sorry for the delay with no answers.

I made some tests and your issue is probably caused by the SPI interrupt handling time. The MasterSetDelay function for kDspiAfterTransfer applies between bytes transmitted from a FIFO, but in your case you are using SPI2 with FIFO size = 1, so each time a byte is transferred then an interrupt is generated and the next frame/byte is transmitted until the interrupt code provides a new byte.

Some things you can try:

- Increase the core frequency. The MK24FN1M0VLL12 can work up to 120 MHz.

- Change the compiler optimization (Properties -> C/C++ Build -> Settings -> Optimization -> Optimization level [-O1, -O2, -O3]).

- Lower the SPI frequency if your LCD accepts it (e.g. to 1 MHz).

- Use SPI0, which has FIFO size of 4.

Playing with these options will give you a better timing to avoid LCD flickering.

I hope this helps!

Jorge Gonzalez

[chadwilliams]

Hi Jorge,

Thanks for replying.

I have now obtain satisfactory performance with the LCD using SPI0 ( 4 byte fifo ) and non-blocking edma. The LCD is a 32 level grayscale 128x128 that required 32768 bytes/screen  when driven in 9 bit 3 wire SPI mode and 16384 bytes when driven in 4 wire 8bit mode.

In regards to the performance of DSPI2 using interrupts which I may use for communicating with other peripherals such as SPIflash, I would still want to optimize

performance. Here's some remarks from my testing.

- Increase the core frequency. The MK24FN1M0VLL12 can work up to 120 MHz.

I attempted to get the CPU running on a core clock of around 95MHz and bus clock of 47.98MHz but ran into possible issues with JTAG communications so I was unable to test operation at that speed.

- Change the compiler optimization (Properties -> C/C++ Build -> Settings -> Optimization -> Optimization level [-O1, -O2, -O3]).

with a 20MHz core clock and with optimization set to   -O0 the time between bytes is  32uS  with -O3  the time between bytes is 14uS .

In my opinion this is still too long for a blocking write.

One thing about PEx/KSDK1.2.0  configuration with DSPI, I learned not to setup a DMA channel for SPI0TX signal, its not nessecary as the DSPI driver handles that.

If you do then you get skipped bytes in the SPI output.... 

Best regards

Chad