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.

CCS/MSP430FR6989: Strange problem with i2c communication baud rate

Part Number: MSP430FR6989
Other Parts Discussed in Thread: MSP-EXP430FR6989

Tool/software: Code Composer Studio

Hello to everybody,

I have a very strange problem with the i2c communication protocol on a Launchpad MSP-EXP430FR6989.
I have set up the DCO with the following settings:

//Set DCO frequency to 1MHz

CS_setDCOFreq(CS_DCORSEL_0,CS_DCOFSEL_0);

//Set SMCLK = DCO with frequency divider of 1

CS_initClockSignal(CS_SMCLK,CS_DCOCLK_SELECT,CS_CLOCK_DIVIDER_1);

and the i2c init parameters are:

    /* Ensure USCI_B0 is in reset before configuring */
    UCB1CTL1 |= UCSWRST;

    /* Set USCI_B0 to master mode I2C mode */
    UCB1CTLW0 |= UCSSEL_3 | UCMODE_3 | UCMST | UCSYNC;

    /**
     * Configure the baud rate registers for 100kHz when sourcing from SMCLK
     * where SMCLK = 1MHz
     */
    UCB1BRW = 10;

    /* Take USCI_B0 out of reset and source clock from SMCLK */
    UCB1CTL1 &= ~UCSWRST;

With this settings everything works fine.

Anyway when I change the DDO frequency to 8 MHz and the SMCLK divider to 8 the program is not able anymore to read the data from the i2c line.

I checked with the scope and the registers byte are correct received from the sensor that I am trying to read while the SCL frequency measured still 100 kHz.

It seems like that the instructions are executed too fast so there is not enough time to read the data received from the bus.

Do you have any idea of where the problem can be?

Thanks a lot for your support!!

  • Each time you change the DCO you're also changing MCLK. MCLK has an initial divisor of /8 [Ref User Guide (SLAU367P) Table 3-7], so in your first example it's running at 125kHz.

    It is possible your I2C code has a race in it, such that it malfunctions if you speed up the CPU (MCLK). Can you post that?

  • Dear Bruce,

    thanks for your help. Finally I figured out that the problem was related to don't check if the RXBUF Interrupt flag was cleared before to read the next byte.

    Thanks again for your kind support,
    Alessandro

**Attention** This is a public forum