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 dataunsigned 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
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...
Thank you very much for your reply, Alvaro Aguilar.
Alvaro Aguilar It seems that this code is for a SLAVE on the bus.
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 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)...
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
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
PTXData = (unsigned char *)TXData; // TX array start address
// Place breakpoint here to see each
// transmit operation.
UCB0CTL1 |= UCTR + UCTXSTT; // I2C TX, start condition
__no_operation(); // Remain in LPM0 until all data
// is TX'd
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
case 12: // Vector 12: TXIFG
if (ByteCtr) // Check TX byte counter
UCB0TXBUF = *PTXData++; // Load TX buffer
ByteCtr--; // Decrement TX byte counter
else
UCB0IFG &= ~UCTXIFG; // Clear USCI_B0 TX int flag
__bic_SR_register_on_exit(LPM0_bits); // Exit LPM0
default: break;
Thank you very much, Alvaro Aguilar.
I appreciate that you posted your code. This code is veryhelpful for me to understand the way to use I2c as masterdevice 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 lengthof bytes receive? When only 5 bytes will be sent from slave, and when master try 6 times i2c_read(), what kindof 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?
Im glad that you found it useful and it is helping you.
OKYDid you use i2c_read() for RX data with unknown lengthof 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.
OKYRXData 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).
Thank you very much again for your reply.
Alvaro Aguilar 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 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.