Jump to content
43oh

I2C USCI_B0 Slave?


Recommended Posts

Wow. I2C is a righteous pain.

 

I thought after getting my bit banging I2C Master routines working that the USCI_B0 Slave routines would be a walk in the park. I was wrong!

 

An old Honeywell ASDXL pressure sensor has gone EOL and I've got the job of making an MSP430 act like one of those old sensors. I know the sensor address is 0xF0 and I know that it pumps out 2 bytes of data. Cool. This should be easy. Nope!

 

I started with the TI sample program:

//******************************************************************************
//  MSP430G2xx3 Demo - USCI_B0 I2C Slave TX single bytes to MSP430 Master
//
//  Description: This demo connects two MSP430's via the I2C bus. The master
//  reads from the slave. This is the slave code. The TX data begins at 0
//  and is incremented each time it is sent. An incoming start condition
//  is used as a trigger to increment the outgoing data. The master checks the
//  data it receives for validity. If it is incorrect, it stops communicating
//  and the P1.0 LED will stay on. The USCI_B0 TX interrupt is used to know
//  when to TX.
//  ACLK = n/a, MCLK = SMCLK = default DCO = ~1.2MHz
//
//                                /|\  /|\
//               MSP430G2xx3      10k  10k     MSP430G2xx3
//                   slave         |    |        master
//             -----------------   |    |  -----------------
//           -|XIN  P1.7/UCB0SDA|<-|---+->|P1.7/UCB0SDA  XIN|-
//            |                 |  |      |                 |
//           -|XOUT             |  |      |             XOUT|-
//            |     P1.6/UCB0SCL|<-+----->|P1.6/UCB0SCL     |
//            |                 |         |             P1.0|--> LED
//
//  D. Dang
//  Texas Instruments Inc.
//  February 2011
//   Built with CCS Version 4.2.0 and IAR Embedded Workbench Version: 5.10
//******************************************************************************
#include "msp430g2553.h"

unsigned char TXData;

void main(void)
{
 WDTCTL = WDTPW + WDTHOLD;                 // Stop WDT
 P1DIR |= BIT0;                            // P1.0 output
 P1SEL |= BIT6 + BIT7;                     // Assign I2C pins to USCI_B0
 P1SEL2|= BIT6 + BIT7;                     // Assign I2C pins to USCI_B0

 UCB0CTL1 |= UCSWRST;                      // Enable SW reset
 UCB0CTL0 = UCMODE_3 + UCSYNC;             // I2C Slave, synchronous mode
 UCB0I2COA = 0xF0;                         // Own Address is now 0xF0h
 UCB0CTL1 &= ~UCSWRST;                     // Clear SW reset, resume operation
 UCB0I2CIE |= UCSTTIE;                     // Enable STT interrupt
 IE2 |= UCB0TXIE;                          // Enable TX interrupt
 TXData = 0xff;                            // Used to hold TX data

 while (1)
 {
   __bis_SR_register(CPUOFF + GIE);        // Enter LPM0 w/ interrupts
 }
}

// USCI_B0 Data ISR
#pragma vector = USCIAB0TX_VECTOR
__interrupt void USCIAB0TX_ISR(void)
{
 UCB0TXBUF = TXData;                       // TX data
 __bic_SR_register_on_exit(CPUOFF);        // Exit LPM0
}

// USCI_B0 State ISR
#pragma vector = USCIAB0RX_VECTOR
__interrupt void USCIAB0RX_ISR(void)
{
 UCB0STAT &= ~UCSTTIFG;                    // Clear start condition int flag
 TXData++;                                 // Increment data
}

 

I figured that I could see if anything happens. Sadly, nothing happens.

 

Would anyone have troubleshooting ideas for me?

Is there a way of making this polling instead of interrupts just to troubleshoot it?

Link to post
Share on other sites

I changed the program to deactivate all interrupts.

 

I'm now just polling the UCB0STAT Status Register to see if there are any changes.

The only flag that changes is the UCBBUSY flag. It says "there's bus activity".

 

Arg!

Link to post
Share on other sites
Would this help?

 

UCB0BR0 = 12;		//fSCL = SMCLK/12 = ~100kHz
UCB0BR1 = 0;

 

Unfortunately, my device is the slave and not the master so, no, that wouldn't help me. :cry:

 

Thanks for the tip though. :thumbup:

Link to post
Share on other sites
I've got I2C slave working on the 2231, I had to flip the SDA and SCL pins though. Might be the case here?

 

Yeah, I had to break out the oscilloscope to do this check.

And, yeah, I needed to swap them.

 

Sadly, it made no positive effect. :cry:

 

Thanks for the tip though :thumbup:

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...