• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 79 subscribers
  • Views 400 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.

MSP432P401R: I2C write when MSP is bus master is causing corrupt transaction

Bhargava Sreekantappa Gayathri
Prodigy 140 points

Part Number: MSP432P401R

Hi,

We have an I2C bus where there are 2 devices. Let's call them device A and device B(MSP432). The communication between the 2 is as follows:

1) to begin, B is a slave on the I2C and A will be the I2C master.

2) A does an I2C write to B.

3) B will switch to I2C master. A will switch to I2C slave.

4) B does an I2C write to A.

and the steps start all over again.

This works most of the time, but occasionally there is a corrupt transaction on the bus. On further analysis, I found that the MSP is holding the SCL line low for an extended period of time after it has received a message from A. I initially thought this was clock stretching, but the MSP is holding the SCL low after it has completely received the data.

I changed the flow to something like this:

1) to begin, B is a slave on the I2C and A will be the I2C master.

2) A does an I2C write to B.

3) B will switch to I2C master. A will switch to I2C slave.

4) On B: while(is_bus_free(i2c));

5) B does an I2C write to A.

With the addition of the while condition, the communication works without any issues. There are no failures after overnight runs. The questions I have are:

1) Why would MSP hold the SCL line low after receiving the message?

2) Is while(is_bus_free(i2c)); ok? Is there a condition when this while loop will never exit? Meaning the bus will be bus forever and thus the fw stuck here for ever.

Thanks,

Bhargav

  • 0
    Guru 96315 points
    Point of terminology: If an agent is holding SCL low (for a "long" time) the clock is being stretched. The Master or Slave can do this.

    There are various times in the protocol when the I2C unit will hold SCL low. These are mentioned in TRM (SLAU356H) Figs 26-9,10,12,13. They have to do with the CPU not servicing TXBUF or RXBUF when needed.

    It's easy to forget that UCTXSTP can take some time to complete. It's not just the raw bus time -- a Stop can (sometimes should) be issued while a byte transfer is in progress, and it's delayed until that byte completes. I expect UCBBUSY is set for the whole time (but I've never looked). Starting a new operation while a UCTXSTP is pending can apparently throw off the state machine [ref NOTE in TRM section 26.3.4.2.2]

    My first guess is that this is what the is_bus_free() check is accomplishing, though the test you describe seems backwards (vs is_bus_busy()).
  • 0 in reply to Bruce McKenney
    TI__Guru 59221 points
    Bhargava,
    I think this is resolved. Please reply if that is not the case.

    Chris

**Attention** This is a public forum