• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 79 subscribers
  • Views 368 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.

MSP430FR5989: Executing Interrupt vectors from RAM

santosh athuru
Prodigy 160 points
Part Number: MSP430FR5989

Hi,

Do you have any example which shows how to have ISRs in RAM (link and load to flash but execute from RAM)? I understand how to relocate the vector table to top of RAM, but I'm trying to execute all or part of my ISRs from RAM as well without fetching anything from FRAM on an LPM wake up.

I'm using IAR compiler tools, if you could point me to such an example it would help.

Also I'm trying to see if there is a way to find out which peripheral (maskable) interrupt occured, for ex:- if I point a few of peripheral interrupts to a same handler, is there a way for me to identify which interrupt occurred within the handler?  In short I'm looking for something similar to SYSSNIV/SYSUNIV but for maskable peripheral interrupts.

Best Regards

Santosh Athuru 

  • 0
    TI__Mastermind 20025 points
    Hi, I will look in the detailed and reply to you later
  • 0 in reply to Xiaodong LI
    TI__Genius 14165 points

    Hi,

    please try this

    // Example ISR showing how to place ISRs to run from RAM
    // This must be done if you don't want the ISR to incur the
    // wake from FRAM penalty from the workaround.
    // Ensure PMM29_workaround.c is included in the project.
    // Port 1 interrupt service routine for CCS
    #pragma CODE_SECTION(PORT_1_ISR, ".TI.ramfunc")
    #pragma vector=PORT1_VECTOR
    __interrupt void PORT_1_ISR(void)
    {

    }

  • 0 in reply to Dietmar Walther
    TI__Genius 14165 points
    Sorry oversaw your 2nd question. I mean each interrupt source has corresponding flags which you should the in the interrupt handler if you combine sources in one ISR.
    Take the Port1 as a simple example the Port1 vector can be sourced by 8 different port pins (if enabled) so you need to check for the P1IFG.x bits to find out which port triggered the interrupt. Such bits exist for each peripheral module.
  • 0 in reply to Dietmar Walther
    Prodigy 160 points

    Hi Dietmar,

    thanks for your response, yes figured out the first one. The second one I understand that the only way to figure out the source of interrupt is to go read the flags from each peripheral, but while doing this there could be more flags set. A single register which could be read would have helped the application better.

    Thanks again for your support. We can close this thread.

    Best regards

    Santosh Athuru

**Attention** This is a public forum