• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 78 subscribers
  • Views 1778 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP430 UCBxCTL1 - UCTXSTT bit-field

James Sanchez
Intellectual 315 points

Although document SLAU208 states "As soon as the slave acknowledges the address, the UCB1CTL1 - UCTXSTT bit-field is cleared.", I don't observe this. Although I am able to successfully complete I2C transfers with connected I2C slave devices withe the MSP430 configured as an I2C master, I notice the UCTXSTT  bit-field remains set after the start condition and slave address have been sourced. I was forced to change my I2C driver SW to poll the UCB1IFG - UCTXIFG bit-field to determine when it was safe to write data to the UCB1TXBUF register, otherwise the code would wait indefinitiely for the UCTXSTT bit-field to be cleared.

Regards, Jim Sanchez 

  

  • 0
    Guru 227245 points

    James Sanchez said:
    "As soon as the slave acknowledges the address, the UCB1CTL1 - UCTXSTT bit-field is cleared.", I don't observe this.

    You don't observe carefuzlly enough. When you wait for the bit to clear, the ACK cycle isn't finished. THis is because in master transmitter mode, teh USCI stretches the ACK cycle until you respond to the TXIFG request. As soon as you write to TXBUF (you already can do it as soon as you set UCTXSTT), the USCI will complete the ACK clock cycle, reset UCTXSTT and either start transmitting or raise UCNACKIFG, discarding the value written to TXBUF, depending on the slave response (or their absence).

    Yes, the double-buffering of the USCI may cause some confusion if one insists of writing straight polling code, without caring for the specifics of the double-buffering mechanisms. :)

**Attention** This is a public forum