• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 78 subscribers
  • Views 1256 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 Master UCSTPIFG interrupt for back to back i2c transactions

TiScoobyDoo
Prodigy 60 points
Other Parts Discussed in Thread: MSP430F5638

I'm using an MSP430F5638 with the USCI in i2c master mode. In my application I have a need to send a number of back to back i2c transactions to a number of devices on the bus. 

The MSP430F5xx interrupt vector register UCBxIV interrupt support for the UCSTPIFG does not exist for the i2c in master mode. I've enabled the interrupt in the UCBxIE, but I don't get interrupts when the STOP bit gets sent on the i2c bus.  While in i2c master mode, I would like to know (preferably by interrupt) when the stop event occurred to mark the completion of an i2c bus transaction. I can then kick off another i2c transaction on the bus. I've seen numerous code examples that simply set the UCTXSTP and then poll in an infinite while loop waiting for the UCTXSTP bit to clear, before the next bus transaction is kicked off. This polling behavior is not desirable for my application.

Page 807 of SLAU208j describes the usage of the UCSTPIFG while is slave mode. It does not state that it's not supported in master mode.

Is the usage of the UCSTPIFG while in i2c master mode supported?

Any tips for determining when to kick off back to back i2c transactions without repeated polling of UCTXSTP or UCBBUSY?

Would I be better off  by sending a restart by setting the UCTXSTT between the transactions instead of setting UCTXSTP?

  • 0
    Guru 227245 points

    TiScoobyDoo said:
    The MSP430F5xx interrupt vector register UCBxIV interrupt support for the UCSTPIFG does not exist for the i2c in master mode.

    When you're master, it's you who sends the stop. So your software already knows that the transmission ended.

    The STPIFG bit is only meant to signal a slave that it got a stop and the current transfer has ended. As the slave cannot know )especially in slave receiver mode) whether the master is done or  not, especially since the master controls the transfer timing and may just take a coffee break - the slave couldn't tell.

    TiScoobyDoo said:
    It does not state that it's not supported in master mode.

    The users guide also doesn't list many other things that aren't supported. Including all things that are not supported is left to the lawyers. For engineers, it is sufficient to list what's supported. If something isn't listed, it can be assumed that it isn't supported.

    TiScoobyDoo said:
    Any tips for determining when to kick off back to back i2c transactions without repeated polling of UCTXSTP or UCBBUSY?

    No. There is no interrupt telling you that you can initiate a new I2C transfer now. However, if there weren't a silicon bug in some MSPs (see errata sheet), you could simply start a new transfer by setting the UCTXSTT bit while stop is stil pending. Any you'll get your interrupts in proper order as soon as the stop is done and start sequence begins. Depending on I2C clock speed (must be sufficient slow), it still works even on those MSPs with this silicon bug. Or with slaves that do not choke on the wrong timing.

    However, if you're not in a multi-master environment, you can as well simple use a repeated start. (in multi-master, it would prevent bus arbitration and no other master could use the bus, but this can be intentional too, especially, if you have to send an address to the slave and then want to read data).

    A repeated start is significantly faster too. First, you spare the STP cycle. Obviously. But since usually the last bit on the bus before end of a transfer is a NACK, and a stop requires a low/high transition (and a NACK is already high), the USCI needs to insert an additional clock cycle between the NACk and the stop. Which can be omitted for a repeated start (however, after an ACK, a repeated start requires an additional clock cycle to bring the data line high).

**Attention** This is a public forum