• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 80 subscribers
  • Views 190 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.

MSP-EXP430F5529LP: UART Tx Interrupt (UCTXIFG)

Yi Zhang
Prodigy 100 points
Part Number: MSP-EXP430F5529LP

UART Tx ready interrupt (UCTXIFG) is been cleared by reading UCA1IV register, so how is the following ISR (This is taken from T.I. sample) suppose to work:

#pragma vector=USCI_A1_VECTOR
__interrupt void USCI_A1_ISR(void)
{
  switch(__even_in_range(UCA1IV,4))
  {
  case 0:break;                             // Vector 0 - no interrupt
  case 2:                                   // Vector 2 - RXIFG
 //   UCA1IFG = 0x02;                       // Manually set the UCTXIFG
    while (!(UCA1IFG&UCTXIFG));             // USCI_A1 TX buffer ready?
    UCA1TXBUF = UCA1RXBUF;                  // TX -> RXed character
    break;
  case 4:break;                             // Vector 4 - TXIFG
  default: break;
  }
}

Below, Rx Buffer has received the "A" from UART and it should put into the Tx buffer next if it's empty (i.e. ready to send), but UCTXIFG was never set. So it waits there forever. If I manually set the UCTXIFG, then it would work, then what's the point of the while loop to wait for the UCTXIFG to be set if I am manually set it right before?

  • 0
    Guru 18845 points

    Case 2 is for the receive interrupt so that clears RXIFG, not TXIFG. (Presumably transmit interrupts aren't even enabled since the ISR does nothing.) TXIFG should be set when TXBUF is empty so you need to find out why it hasn't been set.

    For a simple echo program it should be obvious that the check of TXIFG is useless as TXBUF will always be empty.

  • 0 in reply to David Schultz
    Prodigy 100 points

    Yes, this simple program is to echo whatever is received on Receiver. So when case 2 is triggered, it copied whatever it received to transmit buffer, but before it does so, it checks to see if the transmit buffer is ready or not by looking at the TXIFG signal. The issue is that TXIFG is never set. So the only way is to manually set UCTXIFG before checking...Then the question is what's the point of checking if I just manually set it.

    UCA1IFG = 0x02;                       // Manually set the UCTXIFG

    I can make it work by either removing the checking TXIFG OR manually set TXIFG before checking, but considering this is from T.I.'s example code, there must be a reason behind this?

  • 0 in reply to Yi Zhang
    TI__Genius 17450 points

    The code below

    while (!(UCA1IFG&UCTXIFG));

    Is doing an infinite while loop while the firmware (The msp430 include) is doing the background processes. The background processes are changing the interrupt flags. the TXIFG flag wasn't touched beforehand, but the UCA1IFG was which is why it is in the while loop. You shouldn't have to modify the code to get it to work. Are you using the launchpad and the UART through the usb backchannel? Make sure that the RXD and TXD pins are connected in the Jumper Block. Should look like the image below.

  • 0 in reply to Yi Zhang
    Guru 88580 points

    Your screen capture above shows that UCTXIE=1. This is different from (e.g). MSP430F55xx_uscia1_uart_01.c, which does not set UCTXIE.

    As David (and you) observed, this ISR will not function correctly with UCTXIE=1, so change main() not to set it.

    Is it your goal to (a) write a UART echo program or (b) modify an Example to do something else? Knowing this, we may be able to guide you.

    (Here's the Example I referenced above:

    https://dev.ti.com/tirex/explore/node?node=AO.y3PbPXQlPwKTmMax5Sw__IOGqZri__LATEST

  • 0 in reply to Bruce McKenney47378
    Prodigy 100 points

    Thanks for the reply Bruce. Yes, I did set the UCTXIE = 1 in my main {}, you stated that "this ISR will not function correctly with UCTXIE=1", Can you please elaborate more? Why it wouldn't work if UCTXIE is enabled? Is there a document described this? Thanks

  • +1 in reply to Yi Zhang
    Guru 88580 points

    By setting UCTXIE you cause UCTXIFG to be presented in UCA1IV (case 4); the ISR will then clear UCTXIFG by reading UCA1IV [Ref User Guide (SLAU367P) Sec 30.3.15.4]. As you explained above, since the ISR doesn't do anything with UCTXIFG, that indicator is then lost.

    If you do not set UCTXIE, UCTXIFG will not be presented in UCA1IV, so the ISR will not clear it, and it will stay pending until the UCRXIFG case wants it.

    More generally: If you're not interested in a particular IFG, you should not set the corresponding IE.

  • 0 in reply to Bruce McKenney47378
    Prodigy 100 points

    Thanks Bruce. My original thought was to use the UCTXIFG to check if the UCAxTXBUF is available or not. I guess it's not an interrupt, just a flag. So I shouldn't include it in the interrupt vector UCAxIV? Am I understanding it correctly? 

**Attention** This is a public forum