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 acting strange at 100k, works fine at 400k??

Part Number: MSP430FR2355

I have the MSP430 set up as a master transmitter.  I am not doing any receive.  I am connected to an LCD/RGB module.  When I try and run at 100khz I notice only some bytes come out and then the clock stops (see below).  It seems to choke on the acknowledge of the third byte (consistently).  If I power down the 5V supply that is powering the LCD and change code to 400kHz all is fine again.  Can someone tell me what might be going on and what I have to do in the MSP to get this working at 100kHz???  I feel that fundamentally I may not be doing something correctly in the MSP code that is creating grief.  the code is set up to byte count  I enable the UCTXIE0 and UCBCNTIE (see ISR below)....TI has no good examples in Resource Explorer on how to handle the Busy bit wrt to ISRs or on the byte count or for that matter on clock low

100kHz

Here is the same thing at 400kHz....(works fine)

ISR:

#pragma vector = USCI_B0_VECTOR
__interrupt void I2C_ISR(void)
{
    switch(__even_in_range(UCB0IV, USCI_I2C_UCBIT9IFG))
    {
      case USCI_NONE: break;
      case USCI_I2C_UCALIFG: break;
      case USCI_I2C_UCNACKIFG: break;
      case USCI_I2C_UCSTTIFG: break;
      case USCI_I2C_UCSTPIFG: break;
      case USCI_I2C_UCRXIFG3: break;
      case USCI_I2C_UCTXIFG3: break;
      case USCI_I2C_UCRXIFG2: break;
      case USCI_I2C_UCTXIFG2: break;
      case USCI_I2C_UCRXIFG1: break;
      case USCI_I2C_UCTXIFG1: break;
      case USCI_I2C_UCRXIFG0:
        break;
      case USCI_I2C_UCTXIFG0:
          applicationI2C.pSysCommsB->UCBxTXBUF = *pI2CStream;
          pI2CStream++;
          break;
      case USCI_I2C_UCBCNTIFG:
          applicationI2C.pSysCommsB->UCBxIFG &= ~UCTXIFG;
          ISR.I2CComplete = T;
          LPM3_EXIT;
          break;
      case USCI_I2C_UCCLTOIFG:
          //pI2Cdata.pSysCommsB->UCBxCTLW[0] |= UCSWRST;
          break;
      case USCI_I2C_UCBIT9IFG: break;
      default: break;
    }
}

  • Is this related to your other thread about (apparently) issuing a (new) Start while a previous operation is still running?

    Stating the obvious: The bus runs slower at the lower clock speed; this means that if your code does something at some fixed delay after the Start, the faster I2C clock will get more done in the meantime (it might even finish). 

**Attention** This is a public forum