• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 79 subscribers
  • Views 855 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.

eUSCI I2C multimaster gets stuck

Jesse Frey
Prodigy 220 points
Other Parts Discussed in Thread: MSP430F6779A

I have a project on the MSP430F6779A that uses multimaster I2C. Most of the time it works but occasionally it gets in a state where it can't send data.

What appears to happen is that the UCBBUSY bit gets set when the bus is not busy. When this happens the UCTXSTT is ignored and no interrupts from the I2C module occur.

This error does not happen often so I am still not sure what triggers it but when it does the eUSCI module gets stuck and can't send anything. Originally I could only fix the error by resetting the chip.

I attempted to set the UCSWRST bit and clear it to reset the eUSCI. this did not work

I attempted to clear the UCBBUSY bit (yes I know this is read only). This also did not work even when combined with above

Finally I reset the eUSCI, switched to UART mode, switched back to I2C mode and cleared the UCSWRST bit and this seems to have worked.

Has anyone else had this issue before? I checked the erratta and couldn't find anything that I thought was related

Is there a better way to fix this? The error, currently, happens infrequently enough that I could probably deal with it if I can reliably reset the eUSCI.

  • 0
    Guru 303770 points
    And the I²C bus itself is idle?
  • 0 in reply to Clemens Ladisch
    Prodigy 220 points
    Yes. I am starting to see a correlation between shocking my chair and seeing this error.
    Perhaps the eUSCI picks up some EMI and decides that it is a start condition?
    Also my stated fix does not seem to work. What is the proper way to reset the I2C module so that it thinks the bus is free again?
  • 0 in reply to Jesse Frey
    Guru 92251 points

    Jesse Frey said:
    What is the proper way to reset the I2C module so that it thinks the bus is free again?

    A slave device on the I2C bus is probably pulling SCL or SDA low.

    If the cause is SDA being pulled low by a slave device on the I2C bus, one possible solution is to set the MSP430 SCL and SDA pins to GPIO and toggle the SCL pin until the other device stops holding SDA low. See External Slave Device Hanging the Bus by Holding SDA Low. Once SDA has gone high, the MSP430 SCL and SDA pins can be reconfigured for I2C operation with the eUSCI module.

  • 0 in reply to Chester Gillon
    Prodigy 220 points

    Chester Gillon said:

    Jesse Frey
    What is the proper way to reset the I2C module so that it thinks the bus is free again?

    A slave device on the I2C bus is probably pulling SCL or SDA low.

    This is not the case, both SDA and SCL are high. The other devices on the bus are also MSPs that will timeout if the SCL is low for too long so this should not be an issue. I have also verified the status of SDA and SCL with an oscilloscope. The problem is the eUSCI module. This is fixed by simply resetting the MSP but I was asking if there was a way to reset just the module.

  • 0 in reply to Jesse Frey
    Guru 92251 points

    Jesse Frey said:
    I have also verified the status of SDA and SCL with an oscilloscope. The problem is the eUSCI module. This is fixed by simply resetting the MSP but I was asking if there was a way to reset just the module.

    From reading the MSP430x5xx and MSP430x6xx Family User's Guide SLAU208O I would expect setting and then clearing UCSWRST in I2C mode to clear all bits in the UCBxSTAT register, i.e. to clear UCBBUSY.

    Are the SDA and SCL pins in a high state when UCSWRST is cleared?

    Since it is suspected that EMI triggers the issue, are the SCL and SDA pins still configured for I2C mode?

  • 0 in reply to Chester Gillon
    Prodigy 220 points

    Chester Gillon said:

    Are the SDA and SCL pins in a high state when UCSWRST is cleared?

    Yes. I haven't actually captured at the time that the MSP attempts to send but I have the scope to trigger off of a start condition and it never triggers even though repeated sending attempts are made.

    Chester Gillon said:

    Since it is suspected that EMI triggers the issue, are the SCL and SDA pins still configured for I2C mode?

    Yes. P3SEL still has the correct bits set and the port mapping values are correct.

**Attention** This is a public forum