• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 79 subscribers
  • Views 433909 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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 Relocation MSP430F5659

William Lee73361
Prodigy 40 points
Other Parts Discussed in Thread: MSP430F5529, MSP430F5659, MSP430F6659

I've followed the example code showing how to relocate the interrupt vector table from FF80->FFFF to top of RAM. My code works fine on the MSP430F5529. When I switched over to the F5659, which has a ton more RAM, I get an error "no source for 0x4" which leads me to believe my interrupt vectors are not relocated to the proper place. As a sanity check, I simply memcpy'd the contents of FE80->FFFF to FBE80->FBFFF (top of sector 3 in RAM), just to see if the interrupts would fire.

memcpy((void*)((uint32_t)0xFBE80), (void*)(0xFE80), 0x180 ); // move interrupt vector table to RAM

SYSCTL |= SYSRIVECT;

This does not seem to work on the 5659, anybody have any tips on how to relocate the interrupt vector table for that particular part?

Thanks!

  • 0
    Guru 301570 points

    What example code?

    What address did you try to use?

    "No source for 0x4" is a message from the debugger. But did it actually run?

    The interrupt vector table begins at 0xFF80, not 0xFE80.

  • 0
    Guru 92251 points

    William Lee73361 said:
    memcpy((void*)((uint32_t)0xFBE80), (void*)(0xFE80), 0x180 ); // move interrupt vector table to RAM

    As Clemens has already mentioned the interrupt vector table in flash is only 0x80 bytes, starting at 0xff80.

    Based upon the following in the MSP430x5xx and MSP430x6xx Family User's Guide SLAU208O:

    1.3.6.1 Alternate Interrupt Vectors

    It is possible to use the RAM as an alternate location for the interrupt vector locations. Setting the SYSRIVECT bit in SYSCTL causes the interrupt vectors to be remapped to the top of RAM. Once set, any interrupt vectors to the alternate locations now residing in RAM. Because SYSRIVECT is automatically cleared on a BOR, it is critical that the reset vector at location 0FFFEh still be available and handled properly in firmware.

    And the following in the MSP430F5659 datasheet SLAS700C:

    For a MSP430F5659 I would have expected the following to be used to copy the interrupt vector table from flash to RAM:

      memcpy((void*)((uint32_t)0xFBF80), (void*)(0xFF80), 0x80 ); // move interrupt vector table to RAM
  SYSCTL |= SYSRIVECT;

    However, when I tested this on a MSP430F6659 (same amount of RAM and flash as your MSP430F5659) the program failed and when halted in the debugger the PC was reported as the corrupt value of 0x4 (in peripheral) space.

    As an experiment, the following code was used which copies the interrupt vector table to the highest address in the RAM within the first 64K of address space (the top of RAM sector 0 as listed in the datasheet memory map):

      memcpy((void*)((uint32_t)0x6380), (void*)(0xFF80), 0x80 ); // move interrupt vector table to RAM
  SYSCTL |= SYSRIVECT;

    I also changed the linker command file to exclude the address range for the RAM interrupt vector table to prevent the linker allocating anything else to it:

        RAM                     : origin = 0x2400, length = 0x3f80

    With these changes, the program ran with the interrupt vector table copied to RAM (used a modified version of the MSPware msp430f665x_ta1_04.c     Timer1_A3, Toggle P1.0, Overflow ISR, 32kHz ACLK example)

    Therefore, I think the MSP430x5xx and MSP430x6xx Family User's Guide needs to be clarified about what is "the top of RAM" when the SYSRIVECT bit is set on a device which has some RAM above a 64K address.

    Note that since The datasheet shows that RAM sector 0 at 0063FFh–002400h is also mirrored at the address range 0FFFFFh-0FC000h, the following also works:

      memcpy((void*)((uint32_t)0xFFF80), (void*)(0xFF80), 0x80 ); // move interrupt vector table to RAM
  SYSCTL |= SYSRIVECT;

  • 0 in reply to Chester Gillon
    Prodigy 40 points

    The top of RAM being 0xFFFFF did the trick, and all I had to do was modify the linker cmd as you did to exclude the top of sector 0. I had mine excluding the top of sector 3, which was 0xFBFFF. The mirrored memory part was a clue, but I failed to modify the linker cmd to reflect that the first go round.

    And for posterity - this was the example code I used, the memory address of this part fit nicely under the 64K boundary, as did the 5529, which is probably why this was so confusing.

    processors.wiki.ti.com/.../File:MSP430F5438A_RAM_INT_VECT_CCS.zip

    I guess it's implied that all  interrupt vectors (Flash or RAM based) need to be at an address < 64K.

    Thanks to everybody for their feedback and help!

**Attention** This is a public forum