• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 80 subscribers
  • Views 874 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.

SPI Interfacing TRF7960 with MSP430GF2274 (using ez430-RF2500 kit)

Sedat-G
Prodigy 150 points
Other Parts Discussed in Thread: CC2500, TRF7960

Hi Everyone,

 

I am trying to integrate TRF7960 to ez430RF2500. I know CC2500 on the board is using USCI_B0(SPI). So, by driving STE pin to high, I disabled C2500 from SPI communication. I assigned Port2.0 as SS pin to select TRF7960 for SPI communication. So far there is no problem, when I try to sent consecutive commands to TRF, my software gets stuck. Can someone show me where my mistake is?

 

Part of my code that is related to the SPI comm:

 

 

 DCOCTL=CALDCO_12MHZ;

 BCSCTL1=CALBC1_12MHZ;                     //Clock is set for 3MHZ operation.

 BCSCTL2=DIVM_2 + DIVS_2;

 

 

 UCB0CTL0 = UCMSB + UCMST + UCMODE_2 + UCSYNC;      //Most Significant  Bit, Master Mode and 4-PIN SPI (STE active low) is set.

 UCB0CTL1 = UCSSEL_2 + UCSWRST;            //SMCLK is set.

 CSHI;                                     //Turn OFF CC2500 to SPI. --> POUT &= ~0x01

 UCB0CTL1 &= ~UCSWRST;                     //Initialize SPI Communication.

  SlaveSelectLOW;                           //Turn ON TRF7960 to SPI. --->P2OUT &= ~0x01

 

  //RESET...

  while(!(IFG2&UCB0TXIFG));                 //TXBUF ready??

  UCB0TXBUF = RESET;

  DELAY();

  IFG2 &= ~UCB0TXIFG;

 

  //Reading IRQ status...

  while(!(IFG2&UCB0TXIFG));                //TXBUF Ready??      <----THIS is  WHERE IT STOPS.

  UCB0TXBUF = READ_IRQ;

 DELAY();

 

  UCB0CTL0 &= ~UCCKPH;                     //Switch Clock Polarity.

 

  UCB0TXBUF = 0x00;                        //Dummy write to start Receive

  while(!(IFG2&UCB0RXIFG));

  DELAY();

 

  WRT2MEM(UCB0RXBUF);                      //Write to Info MEM.

 

 

 

 

 

  • 0
    TI__Guru 64530 points

    I believe you are getting stuck on the subsequent check for the UCB0TXIFG is due to possibly a misunderstanding of what that flag represents.

    The MSP430x2xx Family User's Guide (Rev. E) states, in Section 16.3.3 (USCI in SPI mode), the UCB0TXIFG indicates that data has moved from the UCB0TXBUF register to the TX shift register and that the UCB0TXBUF is ready for new data.  It does not indicate RX/TX completion.

    You can use the UCB0RXIFG flag to indicate completion of a transfer, since the SPI interface will be shifting in data on the SOMI pin into the RX shift register as it is shifting out data on the SIMO pin from the TX shift register.

  • 0 in reply to BrandonAzbell
    Guru 227245 points

    BrandonAzbell said:
    You can use the UCB0RXIFG flag to indicate completion of a transfer

    For a slower SPi clock (significantly lower tham MCLK) this is still dangerous, as depending on clock polarity and phase, the RXIFG flag may be set 1/2 clock cycle before completion of the transfer.
    To ensure that the transfer is done (for reconfiguring hardware), the UCBUSY bit shoul dbe checked. If it is clear, then indeed everything is finished.

  • 0 in reply to BrandonAzbell
    Prodigy 150 points

    Thanks for your answer Brandon. This past friday I figured out what my problem was. Actually it was not something related to UCB0TXIFG checking. Also, the reason I was checking this flag to see if the buffer is ready for new data. I was thinking in the same way with you. The problem was about mode selection of SPI communication. I selected 4 wire active low slave SPI communication for my device because the CC2500 was connected in 4 wire. Then I checked UCBOSTAT register to see what the error was and that register showed that there was a bus confliction in the transmission. Somehow, CC2500 and TRF7960 were active at the same time. Then I switched mode to 3-pin wire and used random ports other than STE  for slave select pin and finally, it worked... now I can read from and write into registers.

     

    Thanks again,

    Sedat-G 

  • 0 in reply to Sedat-G
    Guru 227245 points

    4 wire mode is only to be used if you plan to be a slave (either all the time or partially on a multi-master setup). The STE line does not completely act as a chip select line. It will only activate/deactivate the output drivers and the clock recognition and/or switch from master to slave mode (for multi-master). You'll still have to reset the state machine mahually to reset the transfer protocol based on CS. Unfortunately there is no interrupt on an STE change too. (this is one thing I'm missing in the MSPs SPI implementation: optional state reset and/or interrupt on STE change. Currently an additonal port pin is required on Port1/2 for this).

     

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

    In Case, if i get the spi data from a sensor, and if i make the ucb0ste pin high, can i make the cc2500 transmit?

  • 0 in reply to Seby Jacob
    Guru 227245 points

    UCBSTE is only used if the MSP is slave. If the MSP is master, it is useless (unless it is a multi-master bus and the MSP can be addressed as slave). However, I guess you mean the GPIO port output that is on the same physical pin as UCB0STE (controlled by PxOUT while PxSEL or this pin is 0).
    Then yes (with question mark) :)

    If this pin is the chip select for the sensor, then makign it high makes the sensor deaf and silent to the SPI wires. And pulling another pin, connected to the CC2500s CS pin, low, will make the CC2500 listen and talk to the bus. That's how SPI works. There cna be as many slaves on the bus as you have separate I/O pins to control their CS pins. One of them low, all other hight at a time.

**Attention** This is a public forum