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.

MSP430F47187: program is entering in Isr trap routine due to some unknown interrrupt

Part Number: MSP430F47187

We have used uart A0 ,A1,B1. interuupt handelers are also there for all. but still it eneters in isr trap routine. shows some time oscilator interrupt flag / power on interrupt flag set?

how to get out of this issue?

  • Hi,

    to be able to enter an interrupt service routine you need to enable the local interrupt flag for the specific function and the global interrupt flag to allow interrupts. Your described behaviour can have multiple root causes.
    1. If you only expect UART interrupt flags, can you please check that other interrupt flags are disabled?
    2. Which oscillator is used? If it is external 32kHz crystal, is the clock stable?
    3. Power On Interrupt flag may be caused by unstable power supply.

    What do you mean by ISR trap routine? Is the program stoping in the UART ISR or in a different one?

    Best regards,
    Andre
  • We are using uart A1 ,uart A0  ,I2C  & timer A0,A1 interrupts . Issue is, at some point, due to some unknown interrupt ,code gets trapped in Isr trap code . We have now added interrupt routines for NMI ,Timer B0,B1 , WDT, port2 interrupts to find out which  interrupt is causing the code  to jump in  ISR trap routine. Still not able to get out it .

  • Hi,

    please have a look in this e2e thread. It talks about ISR trap routine and ways how to handle it.

    One reason why you might be caught in the ISR trap routine are interrupt flags which are not self clearing. You need to clear them manually.

    Usually you shouldn't use the ISR trap routine, but have specific ISR for each type of interrupt you expect (timer, port, ADC, etc...).

    Best regards,

    Andre

  • Hi,

    We have not used any ISR trap routine .It is already there in the project. Due to some unknown interrupt code pointer is stciking there. We have tried with different small interrupt routines .still not able to sort out the issue.

    Regards,
  • Hi Kalpana,

    Is the application you are running a TI example application or a TI application that was modified?  Is it customized code?

    If you are using CCS or IAR, you should be able to step through your code using breakpoints to see where the program is failing.  Then at the point of failure, drill down into the APIs to find the exact point of failure.  It is probably some variable not initialized properly or its being set to a value that is not correct. 

    You can also verify that the UART interrupts are firing by placing breakpoints within the handlers.

    Regards,

    Arthi 

  • Hi Kalpana,

    do you have further questions? If not, please select "Resolved" in post above so this thread can be closed out.
    Thanks a lot!

    Best regards,
    Andre
  • Hi,

    I suppose that you were able to move on with your application as you didn't reply anymore, so I'll close this post.
    Please feel free to comment again if you look for further assistance, it will re-open the thread.

    Best regards,
    Andre
  • Hi,
    Thank you sir.
    I am using CCS Version: 6.0.1.00040
    I have tried & added all the possible interrupt routines in my code to find out which interrupt causing the program to jump in the trap ISR.
    Tried to check out many of the variables also which may cause this .
    But still the issue is as it is.

    Regards,
    Kalpana Nachnekar
  • "But still the issue is as it is."

    it is crystal clear where the issue is - you haven't provided it yet.

  • Hello Danny,

    Are you able to debug when you are in the trap ISR? If so, can you look at the register view to see which interrupts are enabled and/or which interrupt flags are pending? This should help you narrow down where your issue is. Beyond that, this could be related to USCI28 errata for this part.

    If the above hasn't help, then you will need to trim down your code and add pieces back one at a time to see what causes the. For example, start with your timer routine, test, then add your ADC, test, then your I2C, test, etc. From their you can find out which interrupts are causing the issue.
  • Hi Kalpana,

    have you been able to check the suggestions of Jace above?

    Andre
  • Hi Kalpana,

    has your issue been resolved following Jace' suggestions? Do you still have questions?

    Best regards,
    Andre

**Attention** This is a public forum