• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 80 subscribers
  • Views 551 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.

MSP430FR2355: I2C Bus initializes as busy - cannot proceed with any transaction

Adam Nygard
Prodigy 30 points
Part Number: MSP430FR2355

As the title states - after the initialization of my I2C bus (either on B0 or B1), the STATW register reads that the bus is busy. The controller has been hooked up to a sensor with a pullup and also has been not hooked up to anything, but the problem still persists. The bus says that it's busy right after it exits software reset. My code is below - the two functions are run in succession, any help would be appreciated.

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
void initGPIO()
{
// I2C pins
P1SEL0 |= BIT2 | BIT3;
P1SEL1 &= ~(BIT2 | BIT3);
P1OUT |= BIT2 | BIT3;
// Disable the GPIO power-on default high-impedance mode to activate
// previously configured port settings
PM5CTL0 &= ~LOCKLPM5;
}
void initI2C()
{
UCB0CTLW0 = UCSWRST; // Enable SW reset
UCB0CTLW0 |= UCMODE_3 | UCMST | UCSSEL__SMCLK | UCSYNC; // I2C master mode, SMCLK
UCB0BRW = 160; // fSCL = SMCLK(16MHz)/160 = ~100kHz
UCB0I2CSA = 0x00; // Slave Address
UCB0CTLW0 &= ~UCSWRST; // Clear SW reset, resume operation
}
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0
    Guru 23005 points

    If the I2C bus is busy then something is holding the data line low. If that is a slave that hasn't reset properly you could nudge it a little. Once long ago I added this bit of code to an I2C initialization:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    /*
    Check to see if the bus is busy. If it is, attempt to clear the bus
    by generating a clock manually.
    */
    if (UCB0STAT & UCBBUSY)
    {
    P3DIR &= ~BIT2;
    P3SEL &= ~BIT2;
    P3OUT &= ~BIT2;
    P3DIR |= BIT2;
    P3SEL |= BIT1 + BIT2;
    }
    }
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0 in reply to David Schultz
    Prodigy 30 points

    The main problem is my SDA line. My SCK is high at ~3.3V, but the SDA line is only registering 1.4 - 1.8V. I'm assuming there's a voltage division somewhere on the line but I'm not too sure on how to mitigate this issue.

  • 0 in reply to Adam Nygard
    Guru 96315 points

    The REN resistors are active (if enabled) in I2C mode. Are you using them?

    We had someone here last week who was accidentally using the REN resistors in pull-down, and got your symptom (voltage divider effect).

    [Edit: Minor clarification.]

  • 0 in reply to Bruce McKenney
    Prodigy 30 points

    What you see in the code is the only GPIO modification that's happening - I'm assuming that this isn't messing with pullups/downs but I've also removed that P1OUT line and the same issue persists. Not sure if this contributes to pullups.

  • +1 in reply to Adam Nygard
    Prodigy 30 points

    Turns out my board was broken, I'm still debugging I2C but the floating line was due to P1.2's pullup not engaging, as soon as I switched to a different board everything worked.

**Attention** This is a public forum