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.

USCI-B SPI reading problem while USCI-A works OK

Other Parts Discussed in Thread: MSP430F2274

Hi,
I have spent quite a few hours trying to make the read buffer of USCI-B in the SPI mode (MSP430F2274) work but with no success. It has left me clueless as I checked with a logic analyzer that everything is fine - i.e. when sending a word via USCI-B SPI the clock is there, the Chip Select goes low and the MOSI line issues right characters which makes the MCU on the other side respond at the same time with some data on MISO but this data never gets into UCB0RXBUF.
I am puzzled even more as when I configured the MSP430 for USCI-A and it worked the data from the XX buffer without any asking. The only difference I can see setup-wise is the modulation control at USCI-A but that should be no_impact ? 
Then - is there any difference in configuring the USCI-B for SPI using duplex transmission ? I hope USCI-B can handle standard duplex SPI transmission as USCI-A which I have made work is not a good solution for me as I need RS232 at the same time and I understand USCI-B does not have it ?
I pasted both pieces of code - one for USCI-A working and USCI-B that works only for sending (TX buffer) but shows 0 after reading off the RX buffer:

Pawel

void SPIA_Setup(void)

{

  P3SEL |= 0x31;                            // P3.0,4,5 USCI_A0 option select

  P3SEL &= ~(1<<3); P3DIR |= 0x08;                             // P3.3 Chip Select

  UCA0CTL0 |= UCCKPH + UCMSB + UCMST + UCSYNC;  // 3-pin, 8-bit SPI master

  UCA0CTL1 |= UCSSEL_2;                     // SMCLK

  UCA0BR0 |= 0x10;

  UCA0BR1 = 0;

  UCA0MCTL = 0;

  UCA0CTL1 &= ~UCSWRST;                     // **Initialize USCI state machine**

  P3OUT &= ~0x08;

  UCA0TXBUF = val;

   //Wait for the SPI to indicate that it has finished.

  while (!(IFG2 & UCA0RXIFG));

  data= UCA0RXBUF; 

P3OUT |= 0x08;

// CSN High

RESULT:  Data is OK

 

void SPIB_Setup(void)

{

      P3SEL |= 0x0E;                            // P3.3,2, 3.1 USCI_B0 option select

      P3DIR |= 0x01;                            // P3.0 output direction

      UCB0CTL0 = UCMSB + UCMST + UCSYNC ;       // 4-pin active  LOW, 8-bit SPI mstr, MSB 1

      UCB0CTL1 |= UCSSEL_2;                     // SMCLK

      UCB0BR0 = 0x04*4;

      UCB0BR1 = 0;

      UCB0CTL1 &= ~UCSWRST;                     // **Initialize USCI state machine**

     P3OUT &= ~0x01;                         // CSN_LOW

      UCB0TXBUF = val;

    //Wait for the SPI to indicate that it has finished.

     while (!(IFG2 & UCB0RXIFG));

      data= UCB0RXBUF;

    P3OUT |= 0x01;                          // CSN High

RESULT:  Data = 0

  • Can I ask TI engineers for a short comment if the code for USCI-B that I pasted above looks OK and USCI_B should work in duplex mode without problems and addtional conditions ?

    And hence I should look for a resolution like the PCB or faulty hardware on my side ? That would greatly help me in my project as now I'm stuck with the development.

    Regards,

    Pawel

  • Pawel

    Any luck in solving your problem?  I am having a similar problem with USCI_B0 as a SPI slave.  My post is here http://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/t/145226.aspx. 

     

    Henry

  • Don't know if it's still relevant, but in your USCIA code you used UCCKPH in UCA0CTL0, and in your USCIB you did not.

    In one of my projects I was waiting on the respecitve UCBUSY flag in the UCB0STAT register, it's been quite a while but there are dark memories of something going wrong while waiting on the other flags, like the wait was not long enough and then something was corrupted.

    And yes, USCI_B should work in the SPI mode just like the USCI_A module. And yes USCI_B has no UART(RS232) functionality.

  • Bernhard Weller said:
    USCI_B should work in the SPI mode just like the USCI_A module. And yes USCI_B has no UART(RS232) functionality.

    Indeed, A and B are identical for SPI. The modulation register is meaningless for synchronous transfers and has no effect on the A module in SPI mode (and is not implemented in B, as well as other UART related registers for IrDA or Auto Baud).
    The other differences are that B module has I2C mode (UCMODE_3) and UCSYNC is read-only and always set on B module (since both, SPI and I2C are synchronous)

    For SPI, both are 100% identical.

**Attention** This is a public forum