• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 78 subscribers
  • Views 841 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

I2C on MSP430F5438 - not getting a clock

Jorgen
Prodigy 110 points
Other Parts Discussed in Thread: MSP430F5438

Hi,

I am working with the MSP430F5438 Experimenter board. I am attempting to get I2C working.

Using the user manual to adapt the I2C master files (TI_USCI_I2C_master.c,TI_USCI_I2C_master.h)

I have tried the UCB0 and UCB1 modules.

UCB0 ports are brought out onto the Header RF3 (UCB0SDA P3.1 and UCB0SCL P3.2) while

UCB1 ports are brought out onto the Header Port x.y  (UCB1SDA P3.7 and UCB1SCL P5.4) 

 

Using the following code I would expect the I2C clock start running, but all I see is the clock signal going high and staying there.

void TI_USCI_I2C_transmitinit(unsigned char slave_address,
                          unsigned char prescale){   

/* UCB0 settings */

P3SEL |= SDA_PIN + SCL_PIN;   // Assign I2C pins to USCI_B0

/* UCB1 settings*/

 // P3SEL |= SDA_PIN;
 // P5SEL |= SCL_PIN;

  UCB0CTL1 = UCSWRST;                        // Enable SW reset
  UCB0CTL0 = UCMST + UCMODE_3 + UCSYNC;       // I2C Master, synchronous mode
  UCB0CTL1 = UCSSEL_2 + UCSWRST;              // Use SMCLK, keep SW reset
  UCB0BR0 = prescale;                         // set prescaler
  UCB0BR1 = 0;
  UCB0I2CSA = slave_address;                  // Set slave address
  UCB0CTL1 &= ~UCSWRST;                       // Clear SW reset, resume operation
  UCB0IE = UCNACKIE | UCTXIE;               // Enable TX ready and NACK interrupt
}

I have selected the SMCLK as the input clock to the I2C. Connecting a scope to P4.7 or P1.6(And setting respective PxSEL bits) I see this clock.

Any tips or advice on how to get I2C working would be greatly appreciated.

Thanks,

Jorgen

 

PS:I have not connected anything to the I2C bus yet, but tried connecting the SCL signal to P1.7 configuring it with a pull-up with no change in behaviour.

 

 

 

 

 

 

 

 

 

 

  • 0
    TI__Mastermind 24390 points

    The I2C clock should start only when you send the start condition & Address/RW

    Try running the below example file found in this zip file: http://www.ti.com/lit/zip/slac166

    MSP430x54x_uscib0_i2c_08.c   USCI_B0 I2C Master TX multiple bytes to MSP430 Slave

  • 0
    Intellectual 480 points

    Jorgen,

    Two things:

    1. I do not see where you are specifiying the direction of the ports as . You would need to set: PxDIR

    2. To see the I2C SCL, you would need to send out data constantly and probe using your scope.

    Friendly,
    Engrforever

  • 0 in reply to Engrforever
    Prodigy 110 points

    Thank you to both of you for quick replies. 

    SCL should off course only run while data is in progress :).

    (I started out with a code that did a transfer and a receive, but scaled this back to just init and wrongly expected movement on SCL)

     

    PxDIR are default set as outputs and I have verified that this is true. 

    One thing that I see after the init sequence above is that UCBBUSY is set after init.

     

    I tried adding the MSP430x54x_uscib0_i2c_08.c to my project and calling it. I see that the first value is

    (0x11) is in UCB0TXBUF and that UCBBUSY is set. I am connected to a fan controller (TC655) in this case. UCTXSTT is set, and I am hanging waiting for this flag to be acked and cleared. 

    No movement on the bus, other than SCL going high and staying there.

    Thanks again for your help,

    Jorgen

     

     

    Logic analyzer

  • 0 in reply to Jorgen
    Prodigy 110 points

    I am running this code as part of the userExperienceDemo project. I am using a terminal to send command for tests I want to run through the USB-UART.

    Is there something in this project that might cause these problems?

    -Jorgen

  • 0 in reply to Jorgen
    Intellectual 340 points

    Do you have pullups on both, SDA and SCL?  You only mentioned a pullup on SCL. Maybe that is the problem? The USCI might check if the bus is busy by checking if SDA is low and wait until it goes high. If communication is working, the first thing you should see on the scope is the start condition - which is SDA going low followed by SCL going low.
    Regards,
    Johannes

  • 0 in reply to Johannes Schweidler
    Prodigy 110 points

    I have discovered that connecting SDA to GND does not provide favorable results :(

    Thank you for your help,

    Jorgen

     

**Attention** This is a public forum