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.

problem in interfacing MSP430F2274(MASTER) with PCF8574(slave) ....

Other Parts Discussed in Thread: MSP430F2274, PCF8574

Hi everyone ,

         i'm using  PCF8574P  to interface 7 segment display  with MSP430F2274 micro controller.  i am also  using a example  program  "msp430x22x4_uscib0_i2c_02 "  from " slac123d " this zib file. according to the diagram in the program i have connected the hardware.  i added the program for your reference .

 

Hardware details:

Pullup resistors = 10k(for scl),10k(for sda) , connected with VCC of 2274 (refered  diagram in the program)

PCF8574p slave address : 0x20 ->>>  A0=A1=A2=VSS, grounded

P0 pin of PCF8574 is connected to ground, [VSS]

p1,p2,p3  pins of PCF8574 is connected to supply [VCC]

p4-p7 pins of PCF8574 is connected to 4 pins of 7 segment display , the common pin of 7 segment display is connected to supply

according to the program  [ 7 segment is common anode type so , i connected to supply ] if PCF8574 IC  gets  zero voltage in P0/p1/p2/P3 then one of this segment in P4/P5/P6/P7 segment must glow.

but  if  I run the program the I/O pins PCF8574 P0-P7 is getting voltage 3.35V [ VCC]

so, no 7segment is glowing??????????

can somebody provide me the reason for the problem or the proper Master( Transmit mode ) code with PCF interface .....

 

 

 

 

//******************************************************************************
//  MSP430F22x4 Demo - USCI_B0 I2C Master Interface to PCF8574, Read/Write
//
//  Description: I2C communication with a PCF8574 in read and write mode is
//  demonstrated. PCF8574 port P is configured with P0-P3 input, P4-P7. Read
//  P0-P3 input data is written back to Port P4-P7. This example uses the
//  RX ISR and generates an I2C restart condition while switching from
//  master receiver to master transmitter.
//  ACLK = n/a, MCLK = SMCLK = TACLK = BRCLK = default DCO = ~1.2MHz
//
//                                MSP430F22x4
//                              -----------------
//                  /|\ /|\ /|\|              XIN|-
//                  10k 10k  | |                 |
//       PCF8574     |   |   --|RST          XOUT|-
//       ---------   |   |     |                 |
//  --->|P0    SDA|<-|---+---->|P3.1/UCB0SDA     |
//  --->|P1       |  |         |                 |
//  --->|P2       |  |         |                 |
//  --->|P3    SCL|<-+---------|P3.2/UCB0SCL     |
//  <---|P4       |            |                 |
//  <---|P5       |            |                 |
//  <---|P6       |            |                 |
//  <---|P7       |            |                 |
//   +--|A0,A1,A2 |            |                 |
//   |  |         |            |                 |
//  \|/
//
//  Andreas Dannenberg
//  Texas Instruments Inc.
//  March 2006
//  Built with CCE Version: 3.2.0 and IAR Embedded Workbench Version: 3.41A
//******************************************************************************
#include "msp430x22x4.h"

void main(void)
{
  WDTCTL = WDTPW + WDTHOLD;                 // Stop Watchdog Timer
  P3SEL |= 0x06;                            // Assign I2C pins to USCI_B0
  UCB0CTL1 |= UCSWRST;                      // Enable SW reset
  UCB0CTL0 = UCMST+UCMODE_3+UCSYNC;         // I2C Master, synchronous mode
  UCB0CTL1 = UCSSEL_2+UCSWRST;              // Use SMCLK, keep SW reset
  UCB0BR0 = 12;                             // fSCL = SMCLK/12 = ~100kHz
  UCB0BR1 = 0;
  UCB0I2CSA = 0x20;                         // Set slave address
  UCB0CTL1 &= ~UCSWRST;                     // Clear SW reset, resume operation
  IE2 |= UCB0RXIE;                          // Enable RX interrupt
  TACCTL0 = CCIE;                           // TACCR0 interrupt enabled
  TACTL = TASSEL_2 + MC_2;                  // SMCLK, contmode

  while (1)
  {
    __bis_SR_register(CPUOFF + GIE);        // CPU off, interrupts enabled
    UCB0CTL1 &= ~UCTR;                      // I2C RX
    UCB0CTL1 |= UCTXSTT;                    // I2C start condition
    while (UCB0CTL1 & UCTXSTT);             // Loop until I2C STT is sent
    UCB0CTL1 |= UCTR + UCTXSTT;             // I2C TX, start condition
    __bis_SR_register(CPUOFF + GIE);        // CPU off, interrupts enabled
    while (UCB0CTL1 & UCTXSTT);             // Loop until I2C STT is sent
    UCB0CTL1 |= UCTXSTP;                    // I2C stop condition after 1st TX
  }
}

#pragma vector = TIMERA0_VECTOR
__interrupt void TA0_ISR(void)
{
  __bic_SR_register_on_exit(CPUOFF);        // Exit LPM0
}

// USCI_B0 Data ISR
#pragma vector = USCIAB0TX_VECTOR
__interrupt void USCIAB0TX_ISR(void)
{
  UCB0TXBUF = (UCB0RXBUF << 4) | 0x0f;      // Move RX data to TX
  __bic_SR_register_on_exit(CPUOFF);        // Exit LPM0
}

 

any help could be welcomed on this issue.....

 

  • Still having the problem?

    You have a problem with the program flow.

    You initialize the I2C, then go to sleep.
    The timer wakes the CPU up and you start the read, fine.
    But then you only wait until the start flag is reset. This means that the slave address has been sent and the slave responded (or did not respond, yo don't check for a NAK reply). The slave hasn't send a byte at this point. But you immediately continue with a repeated start condition, giving the I2C no time to ever read the byte from the slave. During the start condition send, the I2C will fire theRX interrupt (why waiting until the transfer has run dry after the repeated start?). Which you answer by putting a never-received 0xff byte into the output.
    Now you set the CPUOFF bit, but the TX ISR had been already fired, so you sleep wait until it (or the timer interrupt) fires again and you put another byte into the output (hopefully the same one, so it won't make a difference to the slave port output).
    Now you wake up, wait for the start bit being clear (which it is), initiating the stop condition.
    Now you once more enter sleep mode and when the timer wakes you up, you immediately start another sequence, not checking whether the stop condition has already been sent properly.

    You see, what the program does is most likely not what you want to have done and what you thought it will do.

**Attention** This is a public forum