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 UCB1 in SPI mode - MSP430F249

Other Parts Discussed in Thread: MSP430F249

Hi,

I'm trying to get the MSP430F249 UCB1 working in 3 pin SPI mode.

This is the code I'm using to initialize the Interface:

// SPI-Hardware initialisieren ////////////////////////////////////////////////

UCB1CTL1 = 1<<UCSWRST;    // SPI-Controller Reset

UCB1CTL1 |= UCSSEL_1;    // ACLK

UCB1CTL0  = UCCKPH + UCMSB + UCMST + UCSYNC + UCMODE_0;  // Phase und Polarität, MSB-First, Master

UCB1BR0   = 4;  // Prescaler 4 -> 0.9MHz

UCB1BR1   = 0;

P5SEL |= (1<<1)|(1<<2)|(1<<3);  // SPI-Leitungen aktivieren

UC1IE |= UCB1RXIE;

UCB1CTL1 &= ~UCSWRST;

In the ISR of UCB1 I'm just doing a dummy read;

//UART_ISR

#pragma vector=USCIAB1RX_VECTOR

__interrupt void SPIB1_RX (void)

{ rx_data=UCB1RXBUF; }

In the main-loop I'm trying to repeatedly send 0xAA (recognizeable pattern 10101010) using the following code:


while(1)

{

spi_adresse(1,0,0);  // set CS

while (!(UC1IFG & UCB1TXIFG));  // buffer ready?

UCB1TXBUF = 0xAA;      // send 0xAA, start transfer

while(UCB1STAT & UCBUSY); // transmission done?

spi_adresse(0,0,0);  // reset CS

}

this is how the data looks like on a logic-analyzer:

 As you can see the controller sends out 7 zeros on the first transmission then stops and resets chip-select. After it starts the second transmission it sends out the same data (not 0xAA) repeatedly. It hangs at "while(UCB1STAT & UCBUSY);".

Because of 7 and not 8 clocks at the first transmission I tried setting the UC7BIT in the UCB1CTL0-register. The controller then sends out only 6 bits at the first transmission. The behaviour after the second transmission is the same, it clocks out data forever.

I just built a second board but it has the exact same behavior, so it shouldn't be a defective µC.

I'm using CCS 5.1.

What am I doing wrong?

 

Andreas Wenzel

 

  • A.Wenzel said:
    UCB1CTL1 = 1<<UCSWRST;    // SPI-Controller Reset

    That's wrong. It willa ctually set bit 1 (since UCSWRST is 1). So for the following initialization, UCSWRST is clear and an unused bit is set. It is undefined what the USCI will do if you alter clock source or configuration while SWRST is clear.

    use
    UCB1CTL1 = 1;
    or
    UCB1CTL1 = UCSWRST;
    instead

  • Thank you,

    after all these years with AVRs I'm still used to bit positions instead of bit patterns in the device-specific header files. 

    Andreas Wenzel 

    edit: I just applied the changes to my code and everything is working like expected. 

  • A.Wenzel said:
    after all these years with AVRs I'm still used to bit positions instead of bit patterns in the device-specific header files. 

    I too work with AVRs, and in our (custom) header files, there are many defines like #define a (b<<c) to map the bit positions into place.
    Since both, MSPs and AVRs are used in the same projects and now share many self-made code modules (with architecture branches, where needed), this mapping unifies it to the use of bit values in the C files.

    Luckily, I started with both systems at the same time, so I didn't get too used for one of them.

    A.Wenzel said:
    edit: I just applied the changes to my code and everything is working like expected. 

    "I love it when a plan comes together." (Colonel John "Hannibal" Smith, The A-Team)

**Attention** This is a public forum