• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 80 subscribers
  • Views 285 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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/MSP430FR2355: Debugger giving strange results on UART

steve wenner
Expert 2355 points

Part Number: MSP430FR2355

Tool/software: Code Composer Studio

I have a UART ISR....Within the receive portion I increment a counter and then wake up from LPM3 to process then go to sleep and wait for next incoming rx data.....I  have a logic analyzer connected to the data streams (tx and rx) and am monitoring them....My first rx stream coming in is "ER_CMD#P9"... I am seeing two strange results:

1.  if I place a breakpoint on __bic_SR_register_on_exit(LPM3_bits); within the rx ISR, the first time through my counter reads 1 yet my RXBUFFER register shows 9??  This is after a reset AND it is the only thing I am receiving in the code.  How is this possible?

2.  Within main I go to sleep then wait to be woken from the rx ISR at which point I have the command

if (UCA1IFG & UCRXIFG) {

within here the first thing I do is read RXBUFFER.  Two concerns here firstly I never break within this which seems to imply the second thing which is according to the USER GUIDE the way you clear the IFG is to read RXBUFFER but it seems to clear on it's own by entering and exiting out of the ISR WITHOUT reading the buffer.....Please comment??

Thanks

  • 0
    Guru 26505 points

    Since you don't show your code I am guessing here.

    I assume that you read the UCA1IV register to find out which interrupt source caused the interrupt. That returns a value for the highest priority interrupt AND resets that interrupt. So looking for RXIFG in the main routine will not work because it was reset. (22.3.15.4 of user guide)

    Your receive ISR should read RXBUF and stash the data somewhere safe. A FIFO queue is what I usually use.

  • 0 in reply to David Schultz
    Expert 2355 points

    David....

    thanks for response...Yes I am rcving as you say but I thought I could get "smart" and trim the ISR down....I don't quite understand what you are saying above however....The manual says you MUST read RXBUFFER to clear the flag and RX is the highest priority....based on what I read I would expect that if I get an RX IFG that I jump into the ISR and clear IF reading RXBUFFER else wake up (see code below) and read RXBUFFER in main (the line that it would wake up to)...

        switch(__even_in_range(UCA1IV, USCI_UART_UCTXCPTIFG))
    {
      case USCI_NONE: break;
      case USCI_UART_UCRXIFG:
          howMany++;
          __bic_SR_register_on_exit(LPM3_bits);
          break;
      case USCI_UART_UCTXIFG:
          __bic_SR_register_on_exit(LPM3_bits);
          break;
      case USCI_UART_UCSTTIFG: break;
      case USCI_UART_UCTXCPTIFG: break;
    }

    Yes it is short either way but this is only the beginning of experimental code where I have to incorporate some other RX/TX stuff.....Main would have looked something like:

            case RESPONSE:
            startTB3();
            __bis_SR_register(LPM3_bits);
            *pRx = UCA1RXBUF;
            pRx++;

  • 0 in reply to steve wenner
    Guru 26505 points

    The manual says that reading RXBUF resets RXIFG but it never says that you must do that or that it is the only way.

    Do not fetishize keeping the ISR short. Do what you need to do.

**Attention** This is a public forum