Long delay between consecutive SPI writes - SAMV71 Xplained

Go To Last Post
5 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

 

I'm testing SPI writes on the SAMV71 and I notice there are always long delays between consecutive writes (~1.8uS)

The SPI clock is running at 9MHz, the MCU is at 300Mhz and the peripheral clock is at 150Mhz

 

The SPI writes work as expected but there always seems to be a 1.8uS delay between each consecutive write - see trace

 

For this test I am just doing an SPI byte write and then waiting for the receive data full RDRF bit to get set:

 

p_spi->SPI_TDR = DAT1;
while (!(p_spi->SPI_SR & SPI_SR_RDRF));
ans1=p_spi->SPI_RDR;

p_spi->SPI_TDR = DAT2;  
while (!(p_spi->SPI_SR & SPI_SR_RDRF));
ans2=p_spi->SPI_RDR;

 

 

Any ideas why such a long delay would occur between the writes?

 

thanks!
 

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

 

I noticed similar issues with AT32UC MCU. There is around 7 usec delay between consecutive SPI byte reads and writes. The CSR.dlybct is set to 0.  Did you figure out the issue?

 

Regards

Last Edited: Tue. Nov 10, 2020 - 05:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have no experience with AT32UC (also none with SAMV71) but, if possible, for the (not uncommon) case where you are sending only try to wait for transmit empty rather than receive full.

If you later actually need to read then the receive buffer must be re-synced (read out data until it is no longer full).

/Lars

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I also saw "long" delays on the SAM D20/21.

 

If it's really a problem for you, you'll need to write your own optimised driver.

 

Please  use the screen capture capabilities of your scope - it'll give far better results than trying to take photographs.

 

https://www.avrfreaks.net/commen...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

The reason for the delay is because the code is waiting for the TX register to fill with data.  This means the second byte will not be transmitted until the first byte has been sent and a byte has been received.  For the fastest speed, wait for the Data register to empty, then feed in the next byte.  The following code just transmits, with no delay between writes.

 

        SERCOM3->SPI.DATA.reg = 0xEE;                                 /* send first char */
        while(!(SERCOM3->SPI.INTFLAG.reg & SERCOM_SPI_INTFLAG_DRE));  /* wait for DRE */
        SERCOM3->SPI.DATA.reg = 0x11;                                 /* send a second char */
        while(!(SERCOM3->SPI.INTFLAG.reg & SERCOM_SPI_INTFLAG_DRE));  /* wait for DRE */

 

If you want to receive also, the best way is to set up an interrupt for RXC

 

 

 

John Malaugh