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.

MSP430FR2476: EusciB as I2C peripheral not working

Part Number: MSP430FR2476

Good morning everyone,

I am not entirely new to the MSP430 world, and I have a decent experience as embedded firmware programmer. Driverlib is something new from my previous experience with MSP430, and 

I find it an excellent tool....once I will be able to make it work.....

I just added this so that once the problem will be solved I will look even more like a fool :).

My problem is that I need to develop a very simple project in which a sensor is connected via I2C to an MSP430 device, and the CPU periodically reads the value.

So far so good....I thought. So, I ordered 2 development kits of MSP430, I read the driverlib documentation and I decided to use the I2C example as a reference. The MSP used in the example are

the FR4133, but I thought the difference was just in the port and pins configuration.

To make the long story short, I am struggling since a few days to have the I2C working! No matter what I try, I always have nothing on my logic analyser, and this is driving me crazy!

I am now in the easiest configuration I can imagine: I have the development board connected via USB to the PC, I have my logic analyser connected to the Eusci_B0 pins which are supposed

to work as I2C (1.3 and 1.2) and I run the basic code that follows

#include "driverlib.h"

volatile uint8_t transmitData;

int main(void) {



    WDT_A_hold(WDT_A_BASE);

    GPIO_setAsPeripheralModuleFunctionInputPin(
        GPIO_PORT_P1,
        GPIO_PIN2 + GPIO_PIN3,
        GPIO_PRIMARY_MODULE_FUNCTION
    );


    PMM_unlockLPM5();
    //Initialize Master
    EUSCI_B_I2C_initMasterParam param = {0};
    param.selectClockSource = EUSCI_B_I2C_CLOCKSOURCE_SMCLK;
    param.i2cClk = CS_getMCLK();
    param.dataRate = EUSCI_B_I2C_SET_DATA_RATE_400KBPS;
    param.byteCounterThreshold = 1;
    param.autoSTOPGeneration = EUSCI_B_I2C_NO_AUTO_STOP;
    EUSCI_B_I2C_initMaster(EUSCI_B0_BASE, &param);

    //Specify slave address
    EUSCI_B_I2C_setSlaveAddress(EUSCI_B0_BASE,
        0x48
        );

    //Set in transmit mode
    EUSCI_B_I2C_setMode(EUSCI_B0_BASE,
        EUSCI_B_I2C_TRANSMIT_MODE
        );

    //Enable I2C Module to start operations
    EUSCI_B_I2C_enable(EUSCI_B0_BASE);
    transmitData = 1;
    while (1)
    {

        //Send single byte data.
        EUSCI_B_I2C_masterSendSingleByte(EUSCI_B0_BASE,
            transmitData
            );

        //Delay until transmission completes
        while (EUSCI_B_I2C_isBusBusy(EUSCI_B0_BASE)) ;

        //Delay between each transaction
        __delay_cycles(50);

        //Increment transmit data counter
        transmitData++;
    }

    return (0);
}

I would expect to see something on the logic analyser, but the signals are never moving (and yes, I double checked that the analyser works....it does).

So, my question is....what is wrong here? I already tried the example codes (singleTX, multipleSlaves, and so on), I already tried a second board, I tried all the possible clock system configurations and clock sources.....always the same issue. The out_of_box example works fine, and I am able also to blink on board leds and to move the pins high/low.....but the I2C does never work!

Please, someone point me to the right direction to understand this weirdness.....what am I missing??

  • Just as additional information....I read the AN concerning common issues and I tried running the i2c_standard_master.c recommended example, which does not use driverlib.....Still no luck, no sign of activity on the pins.

  • My first guess is the pullups -- does your analyzer show the pin state(s) as high or low? The Launchpad doesn't supply the pullups. Some sensor breakout boards supply the pullups.

    In a pinch you might succeed with the internal pullups, something like:

    > GPIO_setAsInputPinWithPullUpResistor(GPIO_PORT_P1, GPIO_PIN2 | GPIO_PIN3);

    Do this before the setAsPeripheralModule call. In the worst case, this call won't hurt anything.

  • Of course, that was it.

    I don't know why (I don't think I read it anywhere), but I assumed this was taken care of in the setAsPeripheralModule call.....
    This fixed this first issue and I am now able to see a first communication on the lines. 

    I have another issue now but I think I will open a separate discussion.

    Thanks a lot for your help!

  • The internal pullups aren't very strong, so you may want to slow the I2C down (100kHz, maybe). And keep your wires fairly short.

**Attention** This is a public forum