• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 79 subscribers
  • Views 4831 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Max SPI speed

Zach Jacobs
Prodigy 30 points
Other Parts Discussed in Thread: MSP430F1611

Hi,

I'm using a msp430f1611 (w/ Salvo RTOS) and I'm running into some issues with the maximum transfer speed with SPI through UART0.  I am using XT2CLK (7.3MHz crystal) for SMCLK and choosing BRCLK to use SMCLK with a divisor of 2.  Other relevant SPI registers below:



  BCSCTL2 |= SELS;                     // SMCLK = XTAL2 (7.3728MHz)

  ME1 |= USPIE0;          //Enable Module  
  U0CTL |= CHAR + SYNC + MM + SWRST;          //SPI, 8-bit data, synchronous mode, master, SWRST
  U0TCTL |= CKPH + SSEL1 + SSEL0 + STC;          //Use SMCLK for BRCLK, Normal clock phase, 3-pin SPI mode
  U0BR0 = 0x02;          //Max clock frequency of bus (BRCLK/2)
  U0BR1 = 0x00;
  U0MCTL = 0x00;          //Modulation control not used

  U0CTL &= ~SWRST;          // Initialize USART state machine
  //IE1 = UTXIE0 + URXIE0;          //Enable TX and RX interrupts


  P3SEL |= BIT1 + BIT2 + BIT3;          //this should set up SPI0 to P3_1:3
  P3DIR |= BIT0;          //Set P3.0 to be GPO to be used for CS in SPI mode
  P3OUT |= SPI_CS;          //initial state is not selected


I configured all registers to the theoretical maximum SPI clock rate BRCLK/2 (~3.6MHz).  Whenever I write to TXBUF0, the data frame shows up twice on the logic analyzer that I am using.  I am able to verify that the clock rate is in fact ~3.6MHz.  However, when I back the SPI clock rate down to BRCLK/8, the frame only shows up once as it should.

Does anyone have any insight as to what is happening?  I am trying to find the max possible spi speed, right now I can only get ~930kHz

Thanks,

Zach

  • 0
    Guru 227245 points

    I used the SPI on a 1611 to communicate with an SD card. I never encountered this and I used it with 4MHz (8Mhz system clock). So I rather suspect your transfer code that stuffs TXBUF.

    With 1/8 of the system clock, a complete SPI transfer takes only 16 clock cycles, which is in the range of the ISR entry/exit overhead. It's possibly a race condition. with BRCLK/8, you have 64 clock cycles per byte. Without a look at the other code, I cannot say more.

    On the 54xx, where the SPI can run with /1, I have only 8 MCLK cycles per Byte to wait for the RX buffer ready, fetching the RX byte and writing the next TX byte (in this order, since if an IRQ comes between writing the next TX byte and fetching the RX byte, you'll lose one byte). I had to write inline-assembly macros to make it work as fast AND compatible as possible. And no ISR at all. For larger transfers, I moved to DMA transfers.

    Two other things:

    Zach Jacobs said:
    U0CTL |= CHAR + SYNC + MM + SWRST;          //SPI, 8-bit data, synchronous mode, master, SWRST

    SWRST should be written BEFORE the other bits are set. The above works if the USART is in PUC configuration (SWRST set after a reset), but might cause problems when you need to recofigure.

    Zach Jacobs said:
       P3DIR |= BIT0;          //Set P3.0 to be GPO to be used for CS in SPI mode
      P3OUT |= SPI_CS;          //initial state is not selected

    You should first set the oputput value and then switch to output to avoid a low-spike on the output pin.

  • 0 in reply to Jens-Michael Gross
    Prodigy 30 points

    Jens-Michael,

    Thanks for the response and suggestions with the configuration registers.

    The issue arose from an incorrectly configured MCLK.  I was using the 32kHz crystal for MCLK instead of the available 7.3MHz XTAL crystal.

    Thanks again for all of the help!!

     

    --Zach

  • 0 in reply to Zach Jacobs
    Guru 227245 points

    Zach Jacobs said:
    I was using the 32kHz crystal for MCLK instead of the available 7.3MHz XTAL crystal.


    Oh, well, that's of course a big problem. The SPI was trying to send almost 14 bytes during a single MCLK cycle, and with a non-synchronized MCLK. No wonder it didn't work :)

    I often worked on a tight schedule, but never THAT tight :)

**Attention** This is a public forum