SPI interbyte delay on K26/K65

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

SPI interbyte delay on K26/K65

1,075 Views
aescov
Contributor I

Hi

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?

scope_2.png

0 Kudos
3 Replies

579 Views
egoodii
Senior Contributor III

'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!

pastedImage_1.png

0 Kudos

579 Views
aescov
Contributor I

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

pastedImage_1.png

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

0 Kudos

579 Views
egoodii
Senior Contributor III

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?

0 Kudos