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

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.

Question on sample code for i2c RX for MSP430F47176

Yasuhiko OKADA
Expert 1900 points
Other Parts Discussed in Thread: MSP430F47176, MSP430F5438


I have a qustion on the sample code for MSP430F47176 using I2C connection.
In the "msp430x471x7_uscib0_i2c_09.c" file, the MSP430 receives data from
other MSP430 throught I2C.

However, in the sample code, I cannot understand what will trigger the TX ISR.
It seems there is no sentence where the UCB0TXBUF is set to trigger the TX ISR.

In the manual (slau056j.pdf), there is a description "The USCI module
automatically acknowledges the received data ..." in the 2nd sentence from
the top of page 21-12. So, does that mean when the I2C slave receives the data,
 acknowledge is automatically sent and will trigger the TX ISR?

However, in the sample code, UCB0TXIE is not set. Does the TX ISR is called

even without setting UCB0TXIE?


I would like to use I2C for SD card module. For that purpose, I am studying
the sample code for TX and RX through I2C.

 

------

Below is the sample code (msp430x471x7_uscib0_i2c_09.c).

//******************************************************************************
//    MSP430x471xx Demo - USCI_B0 I2C Slave RX multiple bytes from MSP430 Master
//
//   Description: This demo connects two MSP430's via the I2C bus. The master
//   transmits to the slave. This is the slave code. The interrupt driven
//   data receiption is demonstrated using the USCI_B0 RX interrupt.
//
//                                 /|\  /|\
//                 MSP430x471xx     10k  10k     MSP430x471xx
//                    slave         |    |        master
//              -----------------   |    |  -----------------
//            -|XIN  P3.1/UCB0SDA|<-|---+->|P3.1/UCB0SDA  XIN|-
//       32kHz |                 |  |      |                 | 32kHz
//            -|XOUT             |  |      |             XOUT|-
//             |     P3.2/UCB0SCL|<-+----->|P3.2/UCB0SCL     |
//             |                 |         |                 |
//
//   K. Venkat
//   Texas Instruments Inc.
//   May 2009
//   Built with CCE Version: 3.2.0 and IAR Embedded Workbench Version: 4.11B
//******************************************************************************
#include "msp430x471x7.h"

unsigned char *PRxData;                     // Pointer to RX data
unsigned char RXByteCtr;
volatile unsigned char RxBuffer[5];       // Allocate 128 byte of RAM

void main(void)
{
  WDTCTL = WDTPW + WDTHOLD;                 // Stop WDT
  P3SEL |= BIT1+BIT2;                            // Assign I2C pins to USCI_B0
  UCB0CTL1 |= UCSWRST;                      // Enable SW reset
  UCB0CTL0 = UCMODE_3 + UCSYNC;             // I2C Slave, synchronous mode
  UCB0I2COA = 0x48;                         // Own Address is 048h
  UCB0CTL1 &= ~UCSWRST;                     // Clear SW reset, resume operation
  UCB0I2CIE |= UCSTPIE + UCSTTIE;           // Enable STT and STP interrupt
  IE2 |= UCB0RXIE;                          // Enable RX interrupt

  while (1)
  {
    PRxData = (unsigned char *)RxBuffer;    // Start of RX buffer
    RXByteCtr = 0;                          // Clear RX byte count
    __bis_SR_register(LPM0_bits + GIE);        // Enter LPM0 w/ interrupts
                                            // Remain in LPM0 until master
                                            // finishes TX
    __no_operation();                       // Set breakpoint >>here<< and read
  }                                         // read out the RxData buffer
}

//------------------------------------------------------------------------------
// The USCIB0 data ISR is used to move received data from the I2C master
// to the MSP430 memory.
//------------------------------------------------------------------------------
#pragma vector = USCIAB0TX_VECTOR
__interrupt void USCIAB0TX_ISR(void)
{
  *PRxData++ = UCB0RXBUF;                   // Move RX data to address PRxData
  RXByteCtr++;                              // Increment RX byte count
}

//------------------------------------------------------------------------------
// The USCIB0 state ISR is used to wake up the CPU from LPM0 in order to
// process the received data in the main program. LPM0 is only exit in case
// of a (re-)start or stop condition when actual data was received.
//------------------------------------------------------------------------------
#pragma vector = USCIAB0RX_VECTOR
__interrupt void USCIAB0RX_ISR(void)
{
  UCB0STAT &= ~(UCSTPIFG + UCSTTIFG);       // Clear interrupt flags
  if (RXByteCtr)                            // Check RX byte counter
    __bic_SR_register_on_exit(CPUOFF);      // Exit LPM0 if data was
}                                           // received

 

 

 

 

  • 0
    Intellectual 705 points

    It seems that this code is for a SLAVE on the bus. If this is what you want, then the other MSP430 (or other master on the bus) has to generate the START condition and the clock for I2C communication to occur. As you can see, you have two interrupts, one that waits for the I2C START condition to occur (the USCIAB0RX_ISR interrupt), and one that takes picks up the byte from UCB0RXBUF once it is ready for pick up (the USCIAB0TX_ISR interrupt).  I know it sounds counter-intuitive, but this is the way that TI has set up the interrupt vectors for the USCI communication peripheral... the USCIAB0TX_ISR takes care of both receiving and transmitting, while the USCIB0RX_ISR takes care of NACK, ACK, STT, STP flags)... 

    Anyway, it is the master that must generate the START condition in order to wake up the SLAVE from its sleep mode...

  • 0 in reply to Alvaro Aguilar1
    Expert 1900 points

    Thank you very much for your reply, Alvaro Aguilar.

    Alvaro Aguilar said:

    It seems that this code is for a SLAVE on the bus.

    Yes. This is used together with MSP430 MASTER sample code.
    I checked this code for studying the way to read data through I2C.

     

    Alvaro Aguilar said:

    As you can see, you have two interrupts, one that waits for the I2C START condition to occur (the USCIAB0RX_ISR interrupt), and one that takes picks up the byte from UCB0RXBUF once it is ready for pick up (the USCIAB0TX_ISR interrupt).  I know it sounds counter-intuitive, but this is the way that TI has set up the interrupt vectors for the USCI communication peripheral... the USCIAB0TX_ISR takes care of both receiving and transmitting, while the USCIB0RX_ISR takes care of NACK, ACK, STT, STP flags)... 

    I see.   So, the USCIAB0RX_ISR interrupt is triggered by the start condition from the master MSP430.
    Then,  USCIAB0TX_ISR is used for picking up the bytes from master MSP430.

    I could understand more on I2C. Thank you very much.

     

    What I really want to do is to make code for TX and RX data from MSP430 as a master device.

    I will study further on the I2C by reading manuals and sample code.

     

    Best regards

     

  • 0 in reply to Yasuhiko OKADA
    Intellectual 705 points

    OKY,

    I just experienced this problem, and I wrote certain functions that would make the MSP430 perform as an I2C master that could read and write to a device on the I2C bus. I was using the MSP430F5438, so the interrupts might be a little different, but for hte most part it should be the same. Basically I first initialize the bus and write the slave address (right justified, first seven bits only, because the hardware takes care of the R/W bit) to the UCB0I2CSA register. --> i2c_init(char slaveAddr). I also wrote a function for reading a specific memory location (it reads one byte at a time only) --> i2c_read (char mLocation).  Finally, I wrote a function that can write up to 4 bytes to the I2C bus (that is all I needed for my application) --> i2c_write (char length)... For the write function, the values must be stored in TXData[] arrary... Here it is:

    ******************************************************************************\

    |  i2c_init takes in a variable and stores it as the address to the slave.     |

    |  Sets up the USCI B0 port as an I2C device with a clock speed of 100kHz.     |

    \******************************************************************************/

    void i2c_init (char slaveAddr) { 

     

        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 = slaveAddr;                    // MD25 Slave Address is 058h

        UCB0CTL1 &= ~UCSWRST;                     // Clear SW reset, resume operation

        UCB0IE |= UCTXIE;                         // Enable TX interrupt

        UCB0IE |= UCRXIE; 

     

    /******************************************************************************\

    |  i2c_read reads a user-defined register from the I2C slave. It reads only    |

    |  one byte, and uses i2c_write to specify desired register.                   |

    \******************************************************************************/

    char i2c_read (char mLocation) {

     

       TXData[0] = mLocation;

       i2c_write (1);                            // Write 1 byte

     

       ByteCtr = 1;                              // RX one byte

       UCB0CTL1 &= ~UCTR;                        // Clear UCTR, be receiver!

     

       while (ByteCtr)

       {

        while (UCB0CTL1 & UCTXSTP);             // Ensure stop condition got sent

        UCB0CTL1 |= UCTXSTT;                    // I2C start condition

        while(UCB0CTL1 & UCTXSTT);              // Start condition sent?

        UCB0CTL1 |= UCTXSTP;                    // I2C stop condition

     

        __bis_SR_register(LPM0_bits + GIE);     // Enter LPM0, enable interrupts

        __no_operation();                       // For debugger

       }  

       return RXData;

    }

     

    /******************************************************************************\

    |  i2c_write puts the specified number of bytes on the I2C bus.                |

    |  This function expects the array of data to be at TXData.                    |

    |  Transmits the array at once, generates STOP afterwards.                     |

    \******************************************************************************/

    void i2c_write (char length) {

     

      ByteCtr = length;                         // Send "length" byte

     

      while (ByteCtr)

      {

        PTXData = (unsigned char *)TXData;      // TX array start address

                                                // Place breakpoint here to see each

                                                // transmit operation.

     

        UCB0CTL1 |= UCTR + UCTXSTT;             // I2C TX, start condition

     

        __bis_SR_register(LPM0_bits + GIE);     // Enter LPM0, enable interrupts

        __no_operation();                       // Remain in LPM0 until all data

                                                // is TX'd

        while (UCB0CTL1 & UCTXSTP);             // Ensure stop condition got sent

      }

    }

     

    Finally, the interrupt routine looks like this (taken from TI's sample code): 

    //------------------------------------------------------------------------------

    // The USCIAB0_ISR is structured such that it can be used to transmit any

    // number of bytes by pre-loading TXByteCtr with the byte count.

    //------------------------------------------------------------------------------

    #pragma vector = USCI_B0_VECTOR

    __interrupt void USCI_B0_ISR(void)

    {

      switch(__even_in_range(UCB0IV,12))

      {

      case  0: break;                           // Vector  0: No interrupts

      case  2: break;                           // Vector  2: ALIFG

     

      case  4:                                  // Vector  4: NACKIFG

        break;

     

      case  6: break;                           // Vector  6: STTIFG

      case  8: break;                           // Vector  8: STPIFG

     

      case 10:                                  // Vector 10: RXIFG

        RXData = UCB0RXBUF;                     // Get RX data

        ByteCtr--;

        P1OUT ^= 0x01;

        __bic_SR_register_on_exit(LPM0_bits);   // Exit active CPU

        break;

     

      case 12:                                  // Vector 12: TXIFG

        if (ByteCtr)                            // Check TX byte counter

        {

          UCB0TXBUF = *PTXData++;               // Load TX buffer

          ByteCtr--;                            // Decrement TX byte counter

        }

        else

        {

          UCB0CTL1 |= UCTXSTP;                  // I2C stop condition

          UCB0IFG &= ~UCTXIFG;                  // Clear USCI_B0 TX int flag

          __bic_SR_register_on_exit(LPM0_bits); // Exit LPM0

        }

        break;

      default: break; 

      }

    }

  • 0 in reply to Alvaro Aguilar1
    Expert 1900 points


    Thank you very much, Alvaro Aguilar.

    I appreciate that you posted your code. This code is very
    helpful for me to understand the way to use I2c as master
    device to read and write data. Also, it can be used to
    quickly test I2c master read and write on my environment.

    After reading your code, I have some quesiton.

    Did you use i2c_read() for RX data with unknown length
    of bytes receive? When only 5 bytes will be sent from slave,
    and when master try 6 times i2c_read(), what kind
    of data is stored at RXData at the 6th time of the
    i2c_read()?

    RXData is written at RXIFG vector of UCB0IV. So, is it
    correct that RXData is not rewritten at the 6th times
    (no data from slave) keeping 5th-time-data?

     

  • 0 in reply to Yasuhiko OKADA
    Intellectual 705 points

    OKY,

    Im glad that you found it useful and it is helping you.

    OKY said:
    Did you use i2c_read() for RX data with unknown length
    of bytes receive?

    No, at any given time I might read one byte or more from my device, so I made my function to read only one byte at a time. However, if I want to read more than one, I run it through a for loop and use a char array to store the results that are returned from the i2c_read function. 

    OKY said:
    RXData is written at RXIFG vector of UCB0IV. So, is it 
    correct that RXData is not rewritten at the 6th times
    (no data from slave) keeping 5th-time-data?

    Not necessarily. The way that i2c_read is written, you must pass the memory location (register) that you wish to read at your slave. Therefore every time you read one byte, you specify which one you want to read before reading it. This works like this: send START condition (with R/W bit low), WRITE register you wish to read, send RESTART condition (this time send R/W bit high), now SLAVE will start sending data until it receives the STOP condition. 

    In my case, the STOP condition is sent immediately after the RESTART condition, therefore I only receive one byte from the SLAVE. If you change the code to receive more than one,  you have to know how many you want to receive every time. Reading outside the range might produce unwanted results. The SLAVE would be in charge of that data, so it can send whatever it wants (my guess is it would just send the next value in the memory).

     

     

  • 0 in reply to Alvaro Aguilar1
    Expert 1900 points

    Thank you very much again for your reply.

    Alvaro Aguilar said:

     Not necessarily. The way that i2c_read is written, you must pass the memory location (register) that you wish to read at your slave. Therefore every time you read one byte, you specify which one you want to read before reading it. This works like this: send START condition (with R/W bit low), WRITE register you wish to read, send RESTART condition (this time send R/W bit high), now SLAVE will start sending data until it receives the STOP condition. 

    I see. For reading data, you specify the address of the data you want. Then, SLAVE will send the data of the address.

    Alvaro Aguilar said:

    In my case, the STOP condition is sent immediately after the RESTART condition, therefore I only receive one byte from the SLAVE. If you change the code to receive more than one,  you have to know how many you want to receive every time. Reading outside the range might produce unwanted results. The SLAVE would be in charge of that data, so it can send whatever it wants (my guess is it would just send the next value in the memory).

    So, the important thing is that I need to know how many bytes I will receive.

    The SD card module (MSC-MOD10 based on uALFAT), I am planning to use, treats various commands. Most commands have response with known bytes. Only boot up message of the module has non-fixed bytes with {CR} at the end of each line of the messages. So problem is only for this boot up message not for other commands. For trearting boot up message, I may try send STOP condition after receiving {CR} of the last line, then avoiding to use the last RXed byte.

**Attention** This is a public forum