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.

  • TI Thinks Resolved

MSP430FR59721: eUSCIA0 Receive interrupt not working

Expert 1985 points

Replies: 15

Views: 1110

Part Number: MSP430FR59721

I have setup the registers and believe that they are correct. I have a baud rate of 115200. I am sending a small message with 5 bytes. I can observe the transmitted data on a CRO and it is correct. I can also connect to a PC and observe it is OK. When I transmit from the PC  (using  Tera term) I do not receive the interrupt. I can see the waveform on the CRO at pin 1 on the MCU. I have GIE set and the receive interrupt enabled. I have no parity  set. 

Any suggestions would be appreciated.



  • I should also say I am using pins 1 & 64 for RXD0 and TXD0. I notice there is another choice on pins 32 & 33. Should I be setting something to select either one of these?

  • In reply to PeterG:

    Hi Peter,

    Yes, there should be a register that allows you to remap the pins, but I don't see this in the documentation. I am looking into this and will let you know what I find.

    Best Regards,


    Don't forget to verify answers to your forum questions by using the  Verify Answer  button.

  • In reply to Eddie LaCost:

    Hi Eddie

    I too have looked at the user guide, data sheet and errata but see not mention of this. I have also looked through all the register names.addresses and can see nothing that resembles this. I look forward to hearing from you as this looks like my problem. 



  • In reply to PeterG:

    I hesitate to disagree with Eddie, but I don't think the FR59 series has anything like the Port MAPper (F5) nor the ReMaP bits (FR2/FR4). I believe it is the case that you use whichever one you pick in the PxSEL bits. (I think it's even possible to use both sets, though I can't tell you what happens if you do this for the RXD side.)

    Do you have any code you can show us? Sometimes all it takes is a typo.

    [Edit: Fixed my own typo.]

  • In reply to Bruce McKenney47378:

    Let me give more details. My MCU is communicating with a 4G module. I sent an AT command to the module and got no activity on the module's transmit pin, my Rx pin. The 4G module has a uart at 1.8V levels so I use a level shifter in between them. To find out which is at fault I disconnected the MCU Tx/Rx lines from the level shifter. In their place I substituted a RS232 board going to a PC. I set up a terminal program for 115200 baud, 8N1. I was able to send AT commands to the 4G module and receives responses. To me, this means the 4g module is not at fault. I then did the reverse and connected my MCU to the RS232 board and repeated the same test. The PC received the command I sent it. I then tried to send bytes to my MCU. I saw no interrupt at all, BUT I could look at pin 1 of the MCU (USCA0RXD) and see data using the CRO. The data was correct. 

    My setup is 

    SetupUART0 bis.b #UCSWRST,&UCA0CTL1 ; Configure UART 0
    bis.b #BIT2+BIT3,&P4SEL0
    bic.b #BIT2+BIT3,&P4SEL1

    bis.b #UCSSEL_2,&UCA0CTL1 ; Set CLK = SMCLK
    ;set up uart0 for baud rate
    mov.b #4,&UCA0BR0 ; 4 for 115200 baud; 52 for 9600
    mov.w #0x05551,&UCA0MCTLW ;0x05551 for 115200; 0x04911 for 9600
    clr.b &UCA0BR1
    bic.b #UCSWRST,&UCA0CTL1 ; release from reset

    I enable the receive interrupt just before I send the data  

    bis.w #UCRXIE,&UCA0IE ;enable receive int
    bic.w #UCRXIFG,&UCA0IFG ;clear flag

    I cannot see what else I can do and am open to any suggestions. I just want the problem solved, whether it is my problem or someone else.

    Thanks for the interest.


  • In reply to PeterG:

    How do you know that you aren't getting an interrupt? Breakpoint? LED?

    What does your ISR look like?

  • In reply to Bruce McKenney47378:

    I have a breakpoint there. I will try a led tomorrow and see if this helps.
    The code is
    eUSCI_A0_INT ;0xFFEE Modem receive
    bic.w #UCRXIFG,&UCA0IFG
    mov.w &UCA0RXBUF,R10
    mov.b R10,0(R6)
    inc R6
    dec.b BYTE_COUNTER
    jnz USARTb ;not the end

    bis #RX_IN,FLAGC
    bic.w #UCRXIE,&UCA0IE ;disable receive int
    USARTb reti

  • In reply to PeterG:

    A breakpoint should do it.

    What is your program doing (best guess) at about the time the byte arrives? LPM? Spin loop?

    Is there any chance your vector is misplaced?
  • In reply to Bruce McKenney47378:

    My program is in a loop waiting for RX_IN to be set. My breakpoint is at the first instruction of the ISR.
    Below is the Vector locations
    ORG 0FFC6h
    DW DUMMY ;oxffc6
    DW DUMMY ;0xffc8
    DW DUMMY ;0xFFca
    DW PORT4_INT ;0xffcc
    DW PORT3_INT ;0xffce
    DW DUMMY ;0xffd0
    DW DUMMY ;0xffd2
    DW PORT2_INT ;0xffd4
    DW DUMMY ;0xffd6
    DW PORT1_INT ;0xffda
    DW TA1_CCR0_INT ;0xffdc
    DW DUMMY ;0xffde
    DW DMA_INT ;0xffe0
    DW DUMMY ;eUSCI_B1_INT ;0xFFe2
    DW TA0_CCR_INT ;0xffe8
    DW DUMMY ;0xffea
    DW eUSCI_B0_INT ;0xffec
    DW eUSCI_A0_INT ;0xffee
    DW DUMMY ;0xFFF0 reserved
    DW WDT_INT ;0xFFF2
    DW TB0_CCR_INT ;F4
    DW TB0_CCR0_INT ;F6

    Thanks for the help

  • In reply to PeterG:

    I'm supposing this is IAR assembly syntax, and I don't have IAR. (CCS uses a separate .section for each vector, so the linker places them.)

    I don't see anything obviously wrong in what you've shown, so the next guess is that it's somewhere else. At this point I would be using the debugger to (a) look at the vector word to make sure it matches (b) check the registers (SR, UCA0IE, UCA0IFG, UCA0CTL0W) to make sure they're what I expected (c) set a breakpoint at the entry point to make sure the program isn't doing a "surprise" Reset.

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.