topic SPI interbyte delay on K26/K65 in Kinetis Microcontrollers

SPI interbyte delay on K26/K65

aescov — Tue, 05 Sep 2017 09:04:44 GMT

Working on optimizing transfer rates to s SPI flash I have observed quite large inter byte/word delay on the SPI bus.

My system is running 120 MHz system clock and 30 MHz SPI clock, and i am using the standard fsl_dspi_edma driver.

When transmitting multiples bytes via DMA, i see that the transfer of the each 8 data bits take about 266ns as expected, but between bytes i see a delay of ~100 ns. Transfer is done with kDSPI_MasterPcsContinuous set.

I was initially using SPI1, and as i was suspecting the delay being related to the missing FIFO on this channel i moved to SPI0 that has 4 level FIFO. However i see the same timing the channel.

Are there any ways to control interword timing on SPI transfers or is the interbyte delay expected behaviour?

Re: SPI interbyte delay on K26/K65

egoodii — Tue, 05 Sep 2017 11:40:38 GMT

'For better or worse' Tpcssck, Tpasc, and Tdt apply between transfers, whether there are CS edges or not.

That being said, I have been unable to squeeze out '1.5 clocks' of internal transfer delay either. I show an extra 50ns below (317ns/byte, rather than 'ideal' 267).

BTW, I hope all that 'ringing' on your clock is due to poor scope grounding --- else you should be looking into some signal termination!

Re: SPI interbyte delay on K26/K65

aescov — Wed, 06 Sep 2017 06:36:18 GMT

Hi Earl

First of all the ringing on SCK is due to my measurement setup.

What did you do reduce the interbyte gap to 50ns.

From the formulas in the reference manual i would expect something like this

System clock 120 MHz - Bus Clock 60 Mhz

PCSSCK=0, CSSCk=0 --> tcsc=(1/60M)*1*2=33,3ns
PASS=0, ASC=0, tasc=(1/60M)*1*2=33,3ns

PDT=0, DT=0, tdt=(1/60M)*1*2=33,3ns

Whith continous PCS only tasc and tcsc components should be in effect, resulting in 66,7ns

However with these settings I stil get ~100ns gaps.

Re: SPI interbyte delay on K26/K65

egoodii — Wed, 06 Sep 2017 10:41:03 GMT

Just to be clear, the diagram you inserted times from one falling-edge to the ensuing rising, which in my picture is indeed 66.7ns --- my calculation is '50ns extra' above the required 1/2-clock 'low' period.

All I can immediately say is that I am actually NOT running a DMA operation --- I have 'nothing else to do at the time' so this is a program loop transfer (which simultaneously drops the words into the CRC engine to net a CRC-check of the upload). Admittedly, it is 'quite hard' to keep up with >3Mtransfers/sec, and I only get this 50ns while the loop can indeed keep the FIFO ahead of 'need'.

Do you know that this DMA-based driver enables full FIFO depth on this channel?