• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 77 subscribers
  • Views 3173 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 SDA Held low on MSP430

Thomas Middleton
Prodigy 20 points
Other Parts Discussed in Thread: TLV320ADC3101

I am seeing variable behaviour when my system is coming up. What the system has is an Altera FPGA powered on a secondary supply and the MSP430 on the primary. The FPGA is the only "master" on the I2C bus, the MSP430 is only ever a "slave". The pull up resistors on the I2C between the two are on the secondary power. Initially the secondary power is off and the MSP430 initializes the I2C Pins (P1.6 P1.7) as inputs. Occasionally, when the MSP430 powers up the secondary power and changes the P1.6 and P1.7 to I2C pins, the SDA line is being held low by the MSP430, it is repeatable on some of our boards, but never shows up on others. The MSP430 seems to hold the I2C SDA line low ad infinitum.

The only work around I have found so far is to issue a "Read+Stop" from the FPGA which will toggle the SCL line 9 times and usually the SCL and SDA lines will go high then. Though, I have seen occasionally where the SCL toggle procedure must be done again.

Part information:
MSP430
430G2403
2BKG4
AQL0A

Thanks,

Tom

  • 0
    Guru 227245 points

    This is strange. A low SDA pin shouldn't happen if the port pins are configured for module use, the USI is in reset, or  is configured for I2C and waiting for the master.

    It is possible that your code misinterprets startup signal edges on SDA and SCL as I2C activity and goes into a lockup state.
    But I don't know of any hardware (USI module) side problem that could cause this.

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

    We were able to find the issue, it was from a partially powered slave device and was due to the sequencing of enabling I2C on the MSP430. We have a TI TLV320ADC3101 CODEC in the system also on the I2C bus which was powered on 3.3VDC, the IOVDD and the AVDD of the CODEC were on the 3.3VDC and the DVDD was on 1.8V which was powered up later. When the I2C was initialised in the MSP430 prior to the CODEC Core coming up, the I2C was being held in an arbitrary state by the CODEC part.

    Thank you,

    Tom

    P.S. What had confused the issue was that the SDA line was being held LOW and when we pulled the SDA pin on the MSP430, the SDA held low issue had "disappeared".

  • 0 in reply to Thomas Middleton
    Guru 227245 points

    Thanks for posting this update. It might help others in future to know where to look for a bug other than in their code.

    Thomas Middleton said:
    P.S. What had confused the issue was that the SDA line was being held LOW and when we pulled the SDA pin on the MSP430, the SDA held low issue had "disappeared".

    Similar issues happen when an unpowered MSP has signals on its inputs. Then some current flows through the clamp diodes, partly powering the MSP. On older MSPs without brownout detection, this could lead to strange effects.

**Attention** This is a public forum