msp432p401r: eUSCI I2C when taken out of reset is UCBBUSY

Hi,
According to the TRM , the reset state of the bit is "0".
Can you verify that before running application code it is indeed "0" (at startup).

Also after you take it out of reset , how are you checking the value - via debug via or code ?

-Priya

Priya Thanigai said:

Hi,
According to the TRM , the reset state of the bit is "0".
Can you verify that before running application code it is indeed "0" (at startup).

Priya Thanigai said:

Hi,
Also after you take it out of reset , how are you checking the value - via debug via or code ?

-Priya

using a debugger.

Eric,
Sorry I haven't had the chance to look back into this.

When you read it - can you try using code to read it after reset?
One of the things I was thinking off was that after a "true" power on reset - it should always read per the UG i.e. '0'.
Perhaps the debugger is emulating a soft reset - and this is not clearing the bit?

-Priya

Hi Eric,

 I'm seeing a similar behavior, most of the time I see UCBBUSY as 1 if I do not have the SCL/SDA pull ups and UCBBUSY as 0 when I have the pull ups.

Also, I always see USBBUSY as 1 when connecting those lines to ground, so I'm not seeing same behavior as you described in your post. Is this something that you can try with a Launchpad??

This is the code that I'm using:

    P10->SEL0 |= BIT2 | BIT3;                // I2C pins

    EUSCI_B3->CTLW0 |= EUSCI_A_CTLW0_SWRST; // Software reset enabled
    EUSCI_B3->CTLW0 = EUSCI_A_CTLW0_SWRST | // Remain eUSCI in reset mode
            EUSCI_B_CTLW0_MODE_3 |          // I2C mode
            EUSCI_B_CTLW0_MST |             // Master mode
            EUSCI_B_CTLW0_SYNC |            // Sync mode
            EUSCI_B_CTLW0_SSEL__SMCLK;      // SMCLK
    EUSCI_B3->CTLW1 |= EUSCI_B_CTLW1_ASTP_2;// Automatic stop generated
                                            // after EUSCI_B0->TBCNT is reached
    EUSCI_B3->BRW = 30;                     // baudrate = SMCLK / 30 = 100kHz
    EUSCI_B3->TBCNT = 0x0005;               // number of bytes to be received
    EUSCI_B3->I2CSA = 0x0048;               // Slave address
    EUSCI_B3->CTLW0 &= ~EUSCI_A_CTLW0_SWRST;// Release eUSCI from reset

    if (EUSCI_B3->STATW && UCBBUSY)
    {
        P1->DIR |= BIT0;
        while(1)
        {
            P1->OUT ^= BIT0;
            for (i = 20000; i > 0; i--);
        }
    }

Also could please run the same test without configuring the SEL0 register (on your custom board)??

Thanks,

 David

Hi Eric,

Were able to run your code on the LP?? Did you get the same behavior??

Please let us know.

Thanks,

David

DavidL said:

Hi Eric,

Were able to run your code on the LP?? Did you get the same behavior??

Please let us know.

Thanks,

David

does the same thing on the Launch Pad.   The key is to allow for the I2C bus to not have power turned on to its pull ups.  If you pull SCL low when first turning the bus on, the UCBUSY is intermitent.  It is weird.  Sometimes it throws UCBUSY sometimes not.   I have not seen SCLLOW as I thought I should.

But we are mistreating the I2C bus, ie. it is out of spec.    But we power down to conserve energy.  Its an ultra low power application and we are going for every little bit.

I don't like how the TI h/w eUSCI is handling this case but I can work around it.