• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 78 subscribers
  • Views 1710 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.

When Entry USCIAB0TX_ISR,the (IFG2 & UCB0TXIFG) have became 0 automatically.

Wiet
Prodigy 95 points 
Here is my code,thank you!
...
I2CSendPtr = 1;
I2CSendBuffer[1] = address;
I2CSendBuffer[0] = data;
...
__bis_SR_register(LPM0_bits + GIE);
...
//First Entry Interrupt

#pragma vector = USCIAB0TX_VECTOR
__interrupt void USCIAB0TX_ISR(void)
{
	if (UCB0TXIFG & IFG2)                           // TX
	{
		UCB0TXBUF = I2CSendBuffer[I2CSendPtr];      // Load TX buffer
		I2CSendPtr--;   ////When Entry Interrupt first,the (IFG2 & UCB0TXIFG) have became 0 automatically in this step!I did nothing!
		if (I2CSendPtr < 0) {
			while (!(IFG2 & UCB0TXIFG));            // wait for tx complete
			IE2 &= ~UCB0TXIE;                       // disable interrupts.
			IFG2 &= ~UCB0TXIFG;                     // Clear USCI_B0 TX int flag
			__bic_SR_register_on_exit(LPM0_bits);   // Exit LPM0
		}
	}
	else if (UCB0RXIFG & IFG2)                      // RX
	{
		I2CRecvBuffer = UCB0RXBUF;                  // store received data in buffer
		__bic_SR_register_on_exit(LPM0_bits);       // Exit LPM0
	}
}

  • 0
    Guru 74080 points

    That's right, because one line above you are filling the TX-buffer with a new character - the TX-IFG will be reset in that case and it is set again when this character is moved to the internal shift register.

  • 0 in reply to Dennis Eichmann
    Prodigy 95 points

      Thank you for response.

      But the TX-IFG is not set again.It keeps zero.

      The PDF of TI  says that TX-IFG is set when TX-buffer is empty.

      The code is part of I2C, the I2c can work in another project. But It doesn't work sometimes.

      I took the two pull-up resistor.

  • 0 in reply to Wiet
    Guru 74080 points

    Yes, the TX-IFG becomes set if the transmit-buffer is ready to pick up a new byte. Remember - the data-byte that is placed into the TX-buffer is not the one that is actually transmitted. If you put your first byte into the TX-buffer and there is no communication running, the byte is immediately put into the TX-shift-register and TX-IFG becomes set again to pick up the second byte. But if there is a running communication the TX-buffer is holding the next byte that will be transmitted after the current byte is finished. In that way the communication is almost continously because the next byte is always ready. Note that you put your byte into the TX-buffer with a parallel 8bit copy at system clock-speed, but the data shift out is serial at (usually) much slower speed.

    If it keeps zero after you copy a byte into the TX-buffer maybe the data-byte is not shifted out of the register because there is an ACK-problem or something like that. What's happening on the data-lines? Have a look with an oscilloscope if possible. Depending on your controller you can also enable interrupts for errors like NACK I think. This helps to figure out your problem.

  • 0 in reply to Dennis Eichmann
    Prodigy 95 points

    Thank you!There are always too many problems that I have to solve.

  • 0
    Guru 227245 points

    From the appearance of ‘I2CSendPtr’ (which actually is no pointer but a counter) I assume it is about I2C communication.
    The general working of TXIFG has already been explained.

    There’s a specific situation that isn’t obvious (even though it should be if one looks at the I2C operation flow diagram in the users guide):
    If a master transmit is started, TXIFG is set immediately. It is expected that one puts the first byte into TXBUF that is to be sent. Exception is if TXSTT and TXSTP have been set simultaneously (a bus scan without actual transmission).

    However, the byte isn’t sent immediately. The USCI first sends the start byte and fetches the ACK bit. It won’t complete the ACK cycle (and clear TXSTT) before something has been written to TXBUF. Once the ACK is received, TXSTT clears, the byte in TXBUF starts to send out, and TXISF is set to get the next byte to send.
    However, it might be that the slave didn’t answer. In this case, TXSTT clears, UCNACKIFG is set and the byte in TXBUF is discarded. TXIFG is not set and the USCI expects you to set UCTXSTP to end the (failed) transfer.

     You didn’t post your init and transfer start code, and didn’t specify the slave, so no further, more specific analysis is possible.

  • 0 in reply to Jens-Michael Gross
    Prodigy 95 points

    Thanks for your good answer.May be the slave device did not work.To be honest,I am confused.

**Attention** This is a public forum