• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 80 subscribers
  • Views 334 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

MSP430F4784: I2C clock and Slave communication

sai devaraj m
Intellectual 340 points
Part Number: MSP430F4784
Other Parts Discussed in Thread: PCA9539

Hi,

I'm currently working on MSP430F4784. In this I'm trying to communicate with two slave devices( Temperature sensor TC74A0 & I/O expander PCA9539 ) using I2C (UCB1).

So far what I'm getting is, while debugging communication with temperature sensor, when executing UCB1CTL1 &= ~UCSWRST; line UCBBUSY is set to 1 and UCSCLLOW is set 1 then in RXBUF I'm getting temperature data. But after a few times of debugging UCBBUSY bit is set 1 and UCSCLLOW bit becomes 0, and data also not receiving RXBUF is always 0.

This happens after the execution of line  UCB1CTL1 &= ~UCSWRST;.

Again it works after some time I power up the IC. It is happening repeatedly.

What causes this issue is there anything I have to configure in I2c to get proper data.

Kindly help me out with this.

Thanks and regards

  • 0
    Guru 100355 points

    For this symptom (bus busy immediately on enabling the I2C)  the first suspect is the bus pullups.

    Are you using a commercial breakout board? These typically include the bus pullups.

  • 0 in reply to Bruce McKenney
    Intellectual 340 points

    Thanks for your response.

    I'm using 10k pullup for I2C bus.

    UCB1CTL1 |= UCSWRST;
    UCB1CTL0 |= UCMST + UCMODE_3 + UCSYNC;
    UCB1CTL1 |= UCSSEL_3 + UCSWRST;
    UCB1BR0 = 11; // fSCL = SMCLK/10 = ~100kHz with SMCLK = 1MHz
    UCB1BR1 = 0;
    UCB1CTL1 &= ~UCSWRST;  <-- the issue occurs in 5:10 ratio here after executing this line( it works fine power on after some break ).

    yes commercial board only.

  • 0 in reply to sai devaraj m
    Guru 100355 points

    If it only fails some of the time, that suggests that one of the devices on the bus is holding SCL low. This can happen (e.g.) if you restart the MCU in the middle of a transaction. The diagnostic here is to disconnect/power-down each of the slaves (one at a time) and see if the condition clears.

    If this is what you're encountering (or even if it isn't yet) you might consider powering each device through a GPIO pin, and power-cycling them at MCU startup. Each of them claims it can run on <=200uA, which is well below the current limit for a GPIO.

  • 0 in reply to Bruce McKenney
    Intellectual 340 points

    Thank you 

    I'll change accordingly

  • 0 in reply to sai devaraj m
    TI__Mastermind 39710 points
    sai devaraj m said:
    UCB1CTL1 &= ~UCSWRST;  <-- the issue occurs in 5:10 ratio here after executing this line( it works fine power on after some break ).

    Hi Sai,

    Have you capture the I2C bus line statues at this time?

    sai devaraj m said:
    line UCBBUSY is set to 1 and UCSCLLOW is set 1 then in RXBUF I'm getting temperature data.

    It is better to capture the I2C waves to see where it failed during the reading operation.

**Attention** This is a public forum