• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 79 subscribers
  • Views 550 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.

Secondary Vector Table

Stan57799
Prodigy 210 points

Other Parts Discussed in Thread: MSP430F249

Someone posted this question in May and the answer included a zip file with an example.  I used this example as a starting point and modified the code to run an an MSP430F249.

I modified "interrupt proxy.asm" I changed all the labels to correspond to the MSP430F249.h header file.  This includes:

     .sect ".brintvec"

     TIMER0_A0_ISR   BR      &TIMER0_A0_PROXY  ; Indirect jump using proxy

 

     .sect  ".mainintvec"

     .word   TIMER0_A0_ISR  ; 0xFFF2 Timer0_A5 CC0

 

The interrupt handler is as follows:

     #pragma vector=TIMERA0_VECTOR
    __interrupt void TIMERA0_Handler( void )
   {
    TimerIntHandler();
   }

 

Looking at the disassembled code:

     location 0xfff2 contains 0xfe64  (this is correct)

     location 0xfe64 contains "BR  &0xbff2"  (this is also correct)

     TIMERA0_Handler appears in the memory map.  The problem is I can't get the address of TIMERA0_Handler into location &0xbff2.

Thanks for the help.

  • 0
    Guru 58965 points

    You need to have a custom link command file to tell the linker that the vector for TIMERA0 is at location 0xBFF2. With that, the linker will put the address of your TIMERA0_Handler in location 0xBFF2.

  • 0
    Guru 227245 points

    The vectors are implicitely placed in a separate segment in flash, the vector table segment. To move the entry, you must move the vector table.
    The default process of generating the voctor entries (the interrupt pragma) assumes every vector at a certain location and only 2 bytes apart.

    There are two ways to circumvent this. First, you can change the offsets of the interrupt vectors so that they are 4 bytes apart and overlap with the code containing the jumps. This will likely cause linker errors.

    Second is to not use the #pragma vector statement at all, but generate a vector table content that points to your jumptable and include the name of each interrupt funciton into this jumptable. This should work fine, does not require any manipulation of the linker files, but of course 'looks' different to the normal way twrit einterrup tfunctions and requires manually entering the function names into the jumpfiled.

    The third way is to tell the liker that the vector table has move to a different location (e.g. from 0xff80-0xfff to 0xfd80-0xfdff (512 bytes moved = one flash segment lower, so you can spare the upper flash segment from rewriting if the application is updated) (in your code, this seems to be 0xbf80)
    Then generate two more segments in the segment list. One for the new and fixed vector table (located at 0xff80--0xffff) which contains jump vectors into your jumpfield, and one segment (e.g. 0xfe00-0xff7f) with the jumpfield, doing the indirect jumps based on the entries of the moved vector table.

    This last one i swhat you tried to do. Just that it is necessary to move the segment location of the vector table segment. It is advised, however, to select a location at the end of flash or the beginning, so it won't divide the normal code flash area into two parts (it needs to be shortened/adjusted anyway), as the linker cannot automatically spread code over two non-adjacent flash segments.

**Attention** This is a public forum