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.

msp430f2013 modified code for uart example



The supplied example, msp430x20x3_ta_uart2400.c, works OK up to the point when there is a timer overflow condition.

As the condition is unhandled a reset occurs.

While this may not matter for just an example, it does matter when you copy, as-is, into your application as the uart driver.

At first I tried catching the overflow condition by checking the TAIV value in the TIMERA0 interrupt handler. Oddly enough I never managed to trap the overflow condition so I tried another tack.

In the TX_Byte function, TAR is zeroed. It is assumed that TX_Byte is called frequently enough to avoid overflow happening. Not an elegant solution but good enough for now.

My modified code has // DH in the comment

// Function Transmits Character from RXTXData Buffer
void TX_Byte (void)
{
  BitCnt = 0xA;                             // Load Bit counter, 8data + ST/SP
 #if 0   // DH original code

  while (CCR0 != TAR)                       // Prevent async capture
    CCR0 = TAR;                             // Current state of TA counter
  CCR0 += Bitime;                           // Some time till first bit

#else // DH new code

   TAR = 0;

   CCR0 = Bitime;

#endif

  RXTXData |= 0x100;                        // Add mark stop bit to RXTXData
  RXTXData = RXTXData << 1;                 // Add space start bit
  CCTL0 =  CCIS0 + OUTMOD0 + CCIE;          // TXD = mark = idle
  while ( CCTL0 & CCIE );                   // Wait for TX completion
}

  • Overflows on 16 bit registers don't do any harm as long as you don't do any < or > comparisons. Since both, TAR and CCR0 overflow the same way, and the ISR is triggered on a == comparison, there is no problem with the original code.

    It's like a runner on a racing track. The goal is 'just another 100 yards'. So no matter how many laps he already did, the next mark is always 100 yards before him.
    Problems arise only if the distance is larger than the size of a lap. But this isn't the case here (Bitime < 65536).

    Your change, however, directly affects the continuity of the TAR. So it may affect any other CCRx job that is currently going on in maybe unrelated code parts. Also, it destroys synchronity, if the tiemr runs with an input divider. Setting TAR=0 doesn't clear the input divider (if the tierm isn't running on full clock). So the next tick might be shorter than expected.

    I wonder which problem you see with the original code. I don't see any unhandled condition that will cause any problem.

  • If you want to disable the overflow interrupt, change the code that sets TAIE (in TACTL).  Don't set that bit.

    If instead you want to handle the overflow interrupt, handle the TIMERA1 interrupt (not only the TIMERA0 interrupt).  The TIMERA0 interrupt is only for CCR0, while the TIMERA1 interrupt is for all the other CCRs and for TAIFG.

    David Henry52307 said:

       TAR = 0;

    This isn't technically safe while the timer is running since you and the timer could both be trying to write to TAR at the same time.  Using TACLR is best.

    Jeff

  • Jeff Tenney said:
    hange the code that sets TAIE (in TACTL)

    Good catch. he didn't post the tiemr init code, so I somewhat misinterpreted the 'overflow condition'.

    *sigh* i wish people would know which part of their code is important for debugging and which part isn't. But if they knew, they wouldn't need help for debugging :(

**Attention** This is a public forum