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

Problem with setting UCTXSTP in I2C routines

Dean Velasco
Intellectual 890 points
Other Parts Discussed in Thread: MSP430F5529

I'm trying to develop some I2C interrupt handlers for an MSP430F5529, but setting the UCTXSTP bit in UCB1CTL1 doesn't work as I expect.   By looking at the "Registers" window, I found out that the UCTXSTP bit isn't always set when I execute UCB1CTL1 |= UCTXSTP.

More specifically, if UCB1STAT == 0x50 (that is, if UCSLLOW and UCBBUSY are asserted) then UCTXSTP doesn't get set.  However, if UCB1STAT == 0x00, then this operation does work.  Is there something that I'm missing, and how can I work around this?

  • 0
    Guru 227245 points

    This is strange.

    While a transfer is ongoing (which implies UCBUSY set), then UCTXSTP should be accepted. If not, it makes no sense setting UCTXSTP.
    UCSCLLOW is set when the USCI sets SCL high but it remains low. This may be due to weak pull-ups (SCL is rising very slowly) or because the slave holds SCL low. Or a different master is using the bus (this could also trigger an arbitration lost interrupt). Or the USCI is holding SCL low itself, because it requires a user input. E.g. in receive mode, RXBUF is full and the next byte is about to be completed too, so RXBUF needs to be read, or start byte in transmit mode has been sent but nothing is in TXBUF. (in this case, setting UCTXSTP would make the USCI continue, fetch the ACK/NACK and then send the stop)

    So the question is: why is SCLLOW set.

**Attention** This is a public forum