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.

Interrupt vector doesn't get linked when defined in asm file, CCS5.3, worked before

Other Parts Discussed in Thread: MSP430G2231

Hello,

After investigation I came out to post question here.

I'm now using CCS 5.3.0.00090.

I want to use some older .asm code (usi slave driver) in new project.

There, USI interrupt vector is defined and it's correctly initialized and put to output file.

Now, creating new project in CCS5.3 I get to problem, that interrupt vector does not get initialized and I don't know what is wrong.

I'm sure that there is an issue with project settings, because if I build my old unmodified project created with older version of CCS i have NO errors and program works as expected.

I have reduced problem to using blink.c example and simple TestIrq.asm file to find issue.

My processor is MSP430G2231.

Here are excerpts from my code:

File blink.c

extern int USI_ISR1;

int main(void) {
 int a;
  WDTCTL = WDTPW | WDTHOLD;        // Stop watchdog timer

    a=USI_ISR1; // to make reference to .asm code

   while (1);
}

File TestIrq.asm:

        .cdecls C,LIST,  "msp430x20x2.h"
        .def    USI_ISR1
        .text
        .align 2
USI_ISR1
            nop
            reti
            .sect   "USI"                  ; USI Vector
            .short  USI_ISR1         
            .end            

Linker uses lnk_msp430g2231.cmd file generated and I get warning:

#10374-D Interrupt vector "USI" does not have an interrupt handler routine.
(OK, there are warnings for other uninitialized interrupt vectors, but USI vector should be initialized!

I will appreciate any help.

Best regards,

Borut.

  • Borut Preloznik said:
    int main(void) {
     int a;
      WDTCTL = WDTPW | WDTHOLD;        // Stop watchdog timer

        a=USI_ISR1; // to make reference to .asm code

       while (1);
    }

    When I created a new project in CCS 6 beta3 using that example code, I found that the compiler optimized away the variable a since it wasn't used, and therefore the USI_ISR1 was not placed in the image by the linker. Also, the .sect "USI" in the assembler file didn't set the interrupt vector (when looked in a hex file of the image).

    With CCS 6 beta3 and TI compiler v4.3.0B1 the following C file:

    #include <msp430.h> 
    
    extern int USI_ISR1;
    
    int main(void) {
      WDTCTL = WDTPW | WDTHOLD;        // Stop watchdog timer
    
       while (1);
    }
    

    And the following assembler file:

            .cdecls C,LIST,  "msp430x20x2.h"
            .def    USI_ISR1
            .intvec ".int04", USI_ISR1
            .text
            .align 2 
    USI_ISR1
                nop
                reti
                .end         

    Resulted in the assembler USI_ISR1 function being linked into the image, and referenced by the USI (INT04) vector at address 0xFFE8

    [I haven't tried this previous versions of CCS or the TI MSP430 compiler]

  • Hello Chester,

    Thanks for trying it out. You gave forced assembler to put vector where intended.

    In the mean time I have installed CCS5.5 and with it compiler and linker produced output as expected. 

    Means, I didn't need to change syntax in any way. I guess (hope) your newer CCS6 beta3 would produce same good result.

    Thank you and best regards,

    Borut.

  • I'm just guessing here, but...

    Your USI vector isn't referenced from anywhere (well, that is expected), so the linker probably drops it. If it were referenced and kept, you wouldn't need a reference to the ISR in main, as it is referenced by the vector.

    Probably you need to generate reference to the USI vector rather than to the USI ISR.

    The '.intvec' instruction Chester used probably does exactly this: force a reference to the USI vector entry, which in turn references the ISR. So the linker doesn't thrown them both away.

    And yes, assigning the USI function pointer to an therwise unised variable is most likely optinmized away by the compiler.
    If it had been a global variable, it might have worked.

**Attention** This is a public forum