• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 78 subscribers
  • Views 1605 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.

I2C RESTART condition - UCRXIFG flag set early

Michael Narayanan
Prodigy 20 points
Other Parts Discussed in Thread: MSP430F5438

Hi,

I am using an MSP430F5438 to communicate, via I2C, with a barometric pressure sensor. To read measurements from the sensor, I write the value of the register I would like to read from and then switch over to master-receiver mode and read in two data bytes. However, before UCTXSTT is even cleared, UCRXIFG is set. The  UCRXIFG flag is clear before I initiate the start but is set as a result of it. I am hoping to understand why!

 

The work around has been to check if UCTXSTT and UXRCIFG are both set. If they are I perform a dummy read to RX buffer to clear the flag. Unfortunately, it doesn't help me figure out why it's doing it. The usual preamble in the user guide states that configuring the USCI module without holding the module in reset could lead unpredictable behavior. For a repeated start I can't place the USCI module in reset while I switch from master-transmitter to master-receiver.

 

Thanks,

Michael.

  • 0
    Guru 227245 points

    Michael Narayanan said:
    However, before UCTXSTT is even cleared, UCRXIFG is set. The  UCRXIFG flag is clear before I initiate the start but is set as a result of it.

    That's the expected behavior for UXTXIFG:
    It is for maximum throughput. TH emoment you start a transmit operation by setting UCTR and UCSTT, UCTXIFG is set, so you can stuff the first byte into TXBUF. The moment UCSTT is cleared, either the content of TXBUF is moved to output shift, TXBUF is empty and UCTXIFG is set again for the next byte, or UCNACKIFG is set (slave didn't answer), and the content of UCTXBUfFis discarded. If you didn't write to TXBUF yet, then if a NACK is received, UCTXIFG gets cleared too.

    If you just want to check for the slave being present, set UCTR and UCSTT, and when UCSTT gets clear, check UCNACKIFG and set UCSTP. Then nothing is sent.

    However, if in your case you really want to receive, you must clear UCTR before setting UCSTT. UCRXIFG should be clear and remain clear until the first byte is received (it won't be ACKed yet). An ACK is sent to the slave when you read RXBUF, a NACK is sent if you set UCSTP or UCSTT..

    But if you read RXBUF first and then set UCSTT (or UCSTP), the USCI will ACK the byte you just read and enter an additional byte receive cycle before it sends the repeated start condition. So set UCSTT (or UCSTP) first and then read RXBUF.

    In the described scenario, send a byte, then receive two bytes, RXIFG should be clear all the time until the first byte is received. If it is set before, you did something wrong. And you should post your code then for analysis.

    Edit: "(or UCSTP)" added above

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

     

    Thanks for the reply.

    I wasn't terminating the read correctly. I should have set UCTXSTP during the reception of the last byte. I was setting it too late  which caused another read cycle. This affected subsequent reads. This can be seen in the first figure which shows the I2C data and clock signal as well as the ouput to P8.5. A third read cycle is generated. Setting UCTXSTP correctly corrected the transaction (second figure). One write, two reads.

    Figure 1.

     

    Figure 2.

     

     

**Attention** This is a public forum