• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 79 subscribers
  • Views 252 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.

MSP430FR5994: Problem with SPI tx pin level after transmission and slow IFG "check"

Tobias Stein
Prodigy 90 points
Part Number: MSP430FR5994


Dear all,

I’m using the UCA2 on an MSP430FR5994 to do some SPI stuff. Having different devices connected i handle the chip select manually.

The initialization is done by this code snippet

SPI_CTLW0 = UCSWRST;
SPI_CTLW0 |= UCSSEL__SMCLK | UCCKPH_1 | UCCKPL__LOW | UC7BIT__8BIT | UCMSB | UCMST__MASTER | UCSYNC | UCMODE_0;
SPI_BRW = 0;
SPI_CTLW0 &= ~UCSWRST;

afterwards i e.g. send a byte by

SPI_TXBUF = byte_to_write;
unsigned int counter = SPI_TIME_OUT_COUNTER;
while ( (!(SPI_IFG & UCTXIFG)) && (counter > 0) ) --counter;

With this implementation i have two problems, I hope you can help me with or point in the right direction:

  1. After sending the byte the level of the tx pin is (often) high and gets only low when e.g. reading and therefore setting the tx-buffer to 0x00. Is there a good fix without the need to send 0x00 afterwards? Did i misconfigure something?
  2. It takes a surprisingly long time (MCLCK = SPI-CLOCK = 4MHz) of approx. 3-4us until the next byte can be send. Is there a better/faster way?

 

Thanks for your help and best wishes

Tobias

  • 0
    TI__Mastermind 28075 points

    Hi Tobias,

    Did you start from one of our example projects? 

    Tobias Stein said:
    After sending the byte the level of the tx pin is (often) high and gets only low when e.g. reading and therefore setting the tx-buffer to 0x00. Is there a good fix without the need to send 0x00 afterwards? Did i misconfigure something?

    Do you mean the MOSI Pin status? The state of MOSI should reflect the last bit transmitted, as it only changes on the appropriate SPI clock edge.  You could reconfigure as a GPIO between transmissions and drive it low, or add a pulldown. 

    Tobias Stein said:
    It takes a surprisingly long time (MCLCK = SPI-CLOCK = 4MHz) of approx. 3-4us until the next byte can be send. Is there a better/faster way?

    It will take at least 2us to send 8 bits at 4MHz, after that you only have about another 4-8 cycles of MCLK before you hit 3-4us. What is your timeout value currently set to? 

    Best Regards,
    Brandon Fisher

**Attention** This is a public forum