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.

Configuring MSP430 Interrupt on PORT1 with GRACE

Other Parts Discussed in Thread: MSP430G2553

I have a behavioral issue that I was hoping someone could help me with. I have a button attached to PORT1 of MSP430G2553, and I have the interrupt configured in GRACE. My interrupt routine is located immediately below my Main() code, and is as follows:

 

// Update input/outputSelection variables after button press

__interrupt void PORT1_ISR(void)
{
inputSelection++;
P1IFG &= ~BIT0; // P1.0 IFG cleared

} 

 

I determined that the code wouldn't compile if this line: #pragma vector=PORT1_VECTOR was in the code. My issue is this: if the button is pressed, the code does go through PORT1_ISR, inputSelection (global variable) is incremented within that ISR, but then once the code returns to the main function, the inputSelection variable is reset back to 0. How can I make the interrupt routine increment a counter that will be accessible in the main program routine?

  • For future reference, if the interrupt is configured in GRACE, then __interrupt is not needed before function definition.

  • Evan Cornell said:
    if the interrupt is configured in GRACE, then __interrupt is not needed before function definition

    Are you sure?
    AFAIK, the _interrupt attribute tells the compiler that it is an interrupt function that needs to save all used registers (including R14/R15, whcih is usually just considered clobbered after a funciton call or contains the return value) and requires a RETI instruction.

    If GRACE configured the interupt, then the function name might be added to the interrupt vector table differently than it is done in normal code (the #pragma etc.) but it is still an interrupt function and the compiler needs to know.

    Or does GRACE generate a separate ISR stub that just calls this function like a normal subfunction? While this would indeed make the _interrupt attribute superfluous (actually destructive), it also is a real performance hog, as it significantly increases ISR latency and memory (stack) usage.

  • I was told by a GRACE expert that the __interrupt  attribute is not needed, so I guess we can assume that GRACE takes care of an ISR stub. I'll have to check later tonight in the GRACE-generated code. 

  • That's correct. Grace generates the ISR stub for you. It also allows you to set the Power Mode on exiting the interrupt, so there should be no limitation on the interrupt functionality.

    We are aware that a function call from the stub isn't the most efficient way of  handling interrupts. We will probably change the interrupt handling of Grace in a future version.

    If you are concerned about this function call, you can of course enable  the interrupt after the Grace initialization and write the interrupt function on your own.

    Regards,

    Michael

**Attention** This is a public forum