How to declare an interrupt handler (ISR) in Mspgcc?

Question

What is the preferred method of declaring an interrupt handler in mspgcc?

Answer 1

Note that this information applies to MSPGCC v4.6.3 which pre-dates the Ti/Redhat/SOMNIUM port of MSPGCC which is now distributed with code composer studio.

Thanks go to Peter Bigot of the Mspgcc-users mailing list for this answer.

There are two possibilities:

A. Use Code composer studio style syntax (has the added benefit of being portable to CCS):

#pragma vector=TIMER0_A0_VECTOR    
__interrupt void
ta0cc0_isr (void)

(Note that this was introduced somewhere around version 20120406 of Mspgcc).

B. Use native gcc syntax:

static void
__attribute__((__interrupt__(TIMER0_A0_VECTOR)))
isr_cc0_TA0 (void)

C. Name the function correctly so that it is included into the vector table (useful for ASM functions).

The interrupt attribute causes the function to be named __isr_X where X is the word offset of the interrupt from the vector table start (equal to the value of the interrupt attribute's parameter divided by 2).

These __isr_X symbols are used to initialize the vector table in crt0ivtbl.o.

Answer 2

Just to clarify, because this is an early Google result.

__attribute__((__interrupt__(TIMER0_A0_VECTOR)))
void __isr_5(void)
{
        ...
}

Current GCC still (I believe this is what arvindpdmn commented about) raises an error, when using above syntax.

internal compiler error: in msp430_attr, at config/msp430/msp430.c:1835
 {
 ^

An issue was raised for this after a report of this in the TI E2E community, but said issue is still in its "Planned" state and it is unclear who the tracker even belongs to. (You can access the issue via the thread in above link.)

Looking at the code, the error is apparently raised, because the only attribute that may have arguments, is the interrupt attribute.

In fact, compilation works fine, if the leading and following underscores are omitted.

This right here is the correct syntax!

__attribute__((interrupt(TIMER0_A0_VECTOR)))
void name_does_not_matter(void)
{
        ...
}

And in fact, this attribute is documented in the official GNU GCC documentation. In retrospect, it is rather unclear where the underscores came from in the first place. So, basically, the only problem here is that the error message is so uninformative.