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.

CCS/MSP430FR4133: MSP430FR4133 - CodeComposer Studui and the TXD - UCTXIFG Flag

Part Number: MSP430FR4133

Tool/software: Code Composer Studio

Dear Ladies and Gentleman!

I use a MSP430FR4133 Microprozessor. This Microprozessor has TXD and RXD for using a UART.

I use the code example for this Microporzessor:

(the code example is from the internet: // Darren Lu // Texas Instruments Inc. // June 2014 // Built with IAR Embedded Workbench v6.10 & Code Composer Studio v6.0

In the Interrupt routine of this Microprozessor Stands:

#if defined(__TI_COMPILER_VERSION__) || defined(__IAR_SYSTEMS_ICC__)

#pragma vector=USCI_A0_VECTOR __interrupt void USCI_A0_ISR(void)

#elif defined(__GNUC__) void __attribute__ ((interrupt(USCI_A0_VECTOR))) USCI_A0_ISR (void)

#else #error Compiler not supported!

#endif { switch(__even_in_range(UCA0IV,USCI_UART_UCTXCPTIFG)) {

case USCI_NONE:

break;

case USCI_UART_UCRXIFG:

while(!(UCA0IFG&UCTXIFG));

// ===== here is the important BIT: UCTXIFG - if this is set

// another Character can be sent!!

UCA0TXBUF = UCA0RXBUF;

__no_operation();

break;

case USCI_UART_UCTXIFG:

break;

case USCI_UART_UCSTTIFG:

break;

case USCI_UART_UCTXCPTIFG:

break;

default: break;

} }

This Code write Bytes to the TXD - and with the oszilloskope I can see the signal.

I use the CCS V6.xx for debugging.

Sometimes the debugger stands at the while(! xxxxxx) still (green marked code).

The register value for UCTXIFG is not correct at this moment.

But this is not logical, because if I use this code at other programm points, it works well.

Can you please give me further information, about the TXD - UCTXIFG Flag when this bit is set, or when this bit is not set?

If have problems during debugging this code!!

If I change the code to === while((UCA0IFG&UCTXIFG) === the program works.

But Darren Lu write the code as ==== while (! xxxx) ==== !!!!!!!!

Please write me an email, with further information about that.

with best regards

Binder

  • Hello Binder,
    I believe Darren is a member of the MSP430 group. The MSP430 team would be the best people to answer why the code was written that way. I will move this thread to the MSP430 forum.

    Thanks
    ki
  • The TXIFG flag indicates that the transmit buffer is empty, which implies that the next byte can be written into it.

    As far as I can see, that interrupt handler has a race condition: when the TXIFG flag is set before RXIFG, the read of UCA0IV register will clear it.
    To fix this, the code has to remember that the transmit buffer is ready:

    {
        static bool tx_ready = false;
    
        switch(__even_in_range(UCA0IV,USCI_UART_UCTXCPTIFG)) {
    
        case USCI_NONE:
            break;
    
        case USCI_UART_UCRXIFG:
            if (tx_ready)
                tx_ready = false;
            else
                while(!(UCA0IFG&UCTXIFG));
            UCA0TXBUF = UCA0RXBUF;
            break;
    
        case USCI_UART_UCTXIFG:
            tx_ready = true;
            break;
    
        case ...
        }
    }

  • Thank you for your comment!

    I think your answer as from your point of view ok - but this is not the exact  problem I have!

    If the while(!(UCA0IFG&UCTXIFG)) Condition stands in the interrupt routine, I works correct.

    If I use this TXD-PIN (or UCA0TXBUF) in a function - which is called from the main routine, the MSP430FR4133 stands still.

    while(!(UCA0IFG & UCTXIFG));
    UCA0TXBUF = 'X';

    I can see that the UCTXIFG = 0 at this moment - but this is not logical, because if the program

    writes to the UCA0TXBUF - the datas should be sent to the TXD-PIN.

    In the DEBUG-Mode I can see that the programm is in this while - routine, and the program

    therefore stands still.

    Can you tell me the reason, why this is??

  • Gerhard Binder said:
    Can you tell me the reason, why this is??

    Not that I'm definitely sure - I'm not having a MSP430 board + CCS to test with.

    But you need to note that debuggers are intrusive. That especially causes problems when viewing system registers. The debugger reads those registers too, and reading often causes clearing of interrupt flags. And this, in turn, causes a different execution path during debugging ...

  • When an interrupt flag is set, the interrupt handler is executed immediately. So the main program will never be able to see this flag.
  • Thank you for that comment - at the moment I think this is the correct answer!
    So for example: I must programm a new interrupt handler, there I make a copy of the
    Interrupt flag - this copy is used in the main programm!

    Thank you I will try this!

    Can you tell me:

    If I write to the  UCA0TXBUF theUCTXIFG is set to 0.

    The the Interrupt routine is called.

    After this back in the main routine the UCTXIFG is 0 and not set to 1.

    Therefore the program stands still.

    Why??

    For example:

    You say, that the main doesn't see the Interrupt flag - but the Interrupt handler or routine is executed!

    I think also that the interrupt handler or routine doesn't affect the UCTXIFG - or if the data are send -

    the UCTXIFG should be again set to 1.

    Therefore the main can react on the UCTXIFG!! - Or is there a change of the UCTXIFG when the interrupt handler is executed!!!


    Sende me further information!!

**Attention** This is a public forum