I2C USCI_B0 Slave?

[zeke 693]

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?

[zeke 693]

Woah! This master is really slow!

 

Would anyone know if the msp430 I2C port can handle a 70hz I2C master?

 

 

Kind of out of spec, eh?

[zeke 693]

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!

[zeke 693]

I may have to implement a bedrock bit banging I2C slave driver.

 

I found this article that has sample code in the appendix:

 

Implementation of MCU Invariant I2C Slave Driver Using Bit Banging.

 

Wish me luck eh?

[dkedr 31]

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

[turd 31]

Would this help?

 

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

[zeke 693]

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:

[zeke 693]

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:

[turd 31]

Do you maybe need to enable the RX interrupt too?

 

IE2 |= (UCB0TXIE | UCB0RXIE);

[zeke 693]

I'll check that out right now.

 

Nope. It doesn't help. I had hope for a minute that it might but nope.

 

Thanks for the suggestion.

[zeke 693]

This is a link for myself.

 

I asked the same question over in the e2e forums.

[V0JT4 34]

Check out USCI I2C documentation, you have to shift device ID >>1, it takes only 7 low bits unlike what you see on the bus. That's the reason why your slave doesn't send ACK.

[zeke 693]

Dude! I owe you.

 

That was it!

 

:clap: :thumbup:

[V0JT4 34]

You're welcome! I've been playing with master side lately. You can find my code for I2C EEPROM like devices in my project thread. It supports write and read with repeated start, 8 or 16 bit EEPROM data address.