• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 80 subscribers
  • Views 9203 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.

MSP430 halts on an trap interrupt in debug mode without using breakpoints

Renato T
Prodigy 30 points

Other Parts Discussed in Thread: MSP430G2333

Hello

I´m facing some problems with unexpected interrupts in debug mode.

I´m using MSP430G2333 and IAR 5.50.1

When I compile and burn the software in DEBUG mode i get the issue. I can´t get the same problem in RELEASE mode, however i don´t know if the issue still occurs or i only didn´t get that.

The issue in debug mode is that MSP430 is entering in my trap interrupt handler and didn´t return to any location.

Checking Erratasheet MSP430G2333 slaz427b.pdf  pag 7 usci 29.

I found:

#######################################################################
USCI29 USCI Module
Function Timing of USCI I2C interrupts may result in call to a reserved ISR location
Description When certain USCI I2C interrupt flags (IFG) are set and an automatic flag-clearing event
on the I2C bus occurs, the device makes a call to the TRAPINT interrupt vector. This will
only happen if the IFG is cleared within a critical time window (~6 CPU clock cycles)
after a USCI interrupt request occurs and before the interrupt servicing is initiated. The
affected interrupts are UCBxTXIFG, UCSTPIFG, UCSTTIFG and UCNACKIFG.
The automatic flag-clearing scenarios are described in the following situations:
(1) A pending UCBxTXIFG interrupt request is cleared on the falling SCL clock edge
following a NACK.
(2) A pending UCSTPIFG, UCSTTIFG, or UCNACKIFG interrupt request is cleared by a
following Start condition.
Workaround (1) Poll the affected flags instead of enabling the interrupts.
(2) Define an ISR for the interrupt vector TRAPINT. If the failure condition occurs; a call
to the TRAPINT ISR is made. After the interrupt is serviced, the device returns to the
application code and continues execution.
Include the following ISR definition in the application code.
#pragma vector= TRAPINT_VECTOR
__interrupt void TRAPINT_ISR(void)
{
__no_operation();
}
For IDE versions earlier than IAR V4.22 and CCS V4.2 in addition to the above code;
include the ISR definition in the device header file.
In IAR Embedded Workbench include the following line in the device header file
MSP430x23x0.h.
/************************************************************
* Interrupt Vectors (offset from 0xFFE0)
************************************************************/
#define TRAPINT_VECTOR (0* 2u) /*INCLUDE THIS LINE IN .h FILE*/
#define PORT1_VECTOR (2 * 2u) /* 0xFFE4 Port 1 */
In Code Composer Essentials/Studio include the following line in the device header file
MSP430x23x0.h.
/************************************************************
* Interrupt Vectors (offset from 0xFFE0)
************************************************************/
#define TRAPINT_VECTOR (0 * 1u) /*INCLUDE THIS LINE IN .h FILE*/
#define PORT1_VECTOR (2 * 1u) /* 0xFFE4 Port 1 */
#######################################################################

So I suspect that it´s related to this i2c issue.

I have tested 3 situations:

1 - Running at debug mode with J-TAG

2 - Running at debug mode without any J-TAG (just compiled and burned msp in debug mode)

3 - Running at Release mode without J-TAG

Results:

1 - MSP430 halts (lock). Than I Break the software and it´s stopped on TRAPINT_VECTOR. Why it´s stopped there? If I click on GO , MSP430 continues to run normally

2 - MSP430 halts (lock) and only returns to run if i remove 3v3 power supply

3 - I can´t get the issue, maybe because i haven´t tested it too much, however I think it will occur to.

 

Accordantly to USCI29 bug

I suppose that with the trap handler my software needs to continue even if the traps occur.

 

I also tested with CCS5.3.0 and get the same problem

 

So my question is: Is it happening because i´m compiling in debug mode? Will it happens also in RELEASE mode?!

Thanks in advance

  • 0
    TI__Guru* 83021 points

    Hi Renato,

    I'm trying to understand your issue. Could you please post your TRAPINT_ISR code? Does it exactly match the ISR from the errata doc:

    #pragma vector= TRAPINT_VECTOR

    __interrupt void TRAPINT_ISR(void)

    {

    __no_operation();

    }

    It sounds like you have this ISR, and you put a breakpoint there to see if your code is entering this workaround ISR. If this is true, the reason this doesn't hit in release mode is because you can't really put breakpoints on just any line of C code due to optimizations - see this thread in the CCS forum: http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/86021/297301.aspx#297301.

    You can do a different test however if you want to confirm the fix in your release mode code - you can take an unused GPIO on your design, initialize it as an output at the top of your code, then add a line of code to your TRAPINT_ISR to toggle this pin (something like P1OUT ^= BIT0 for example). This way you can observe with a scope that the ISR has been entered if the pin ever toggles. After your testing you could take this pin toggling back out since it's not necessary for your application.

    Hope this helps!

    Regards,

    Katie

  • 0 in reply to Katie Pier
    Guru 46710 points

    Katie Enderle said:
    you can't really put breakpoints on just any line of C code due to optimizations

    ...Or CPU architecture. Breakpoint on lone NOP standing in the ISR can give strange debug results. Better "bracket" your breakpoint NOP with couple more NOP's and see results.

  • 0 in reply to Katie Pier
    Prodigy 30 points

    Hi Katie

    My code:

    #pragma vector= TRAPINT_VECTOR

    __interrupt void TRAPINT_ISR(void)

    {

        u8TrapCount++;

    }

    I have also changed my msp430g2333.h file

    Added this line

    #define TRAPINT_VECTOR (0 * 2u)

    About your question.

    No, i´m not trying to put a breakpoint on trapint on Release mode. Even because I´m not using j-tag.

    What looks stranges to me is : why msp430 locks when software enters in trap isr ! Note: I´m didn´t put any breakpoint on this function. I can see that it stopped there because i break the software while it´s running

    I will try to toggle one I/O to check if trap isr handler is also being called in release mode, but software is returning to executed normally

    Thanks

     

     

  • 0 in reply to Renato T
    TI__Guru* 83021 points

    Hi Renato,

    Thanks for the additional information.

    Renato T said:

    What looks stranges to me is : why msp430 locks when software enters in trap isr ! Note: I´m didn´t put any breakpoint on this function. I can see that it stopped there because i break the software while it´s running

    Before you pause the debug to see where it is, is the MSP430 no longer behaving normally? Or are you just pausing to see where it is?

    Regards,

    Katie

  • 0 in reply to Katie Pier
    Prodigy 30 points

    Katie

    MSP430 doesn´t behaves normally, it´s locked. Then I pause the software to see where it is.

    Thaks

  • 0 in reply to Renato T
    Guru 227245 points

    Since your trap ISR doesn't handle the interrupt (clear the IFG bit that caused it or disable the IE bit that enabled it), your ISR will be entered right after exit in an endless loop.
    Mmain won't execute anymore, and only higher-priority interrupts than the trapped one will be executed.

  • 0 in reply to Jens-Michael Gross
    TI__Guru* 83021 points

    Jens-Michael Gross said:

    Since your trap ISR doesn't handle the interrupt (clear the IFG bit that caused it or disable the IE bit that enabled it), your ISR will be entered right after exit in an endless loop. Mmain won't execute anymore, and only higher-priority interrupts than the trapped one will be executed.

    What he is implementing is not a true trap isr for a normal interrupt, but rather, a workaround for USCI29 found here: www.ti.com/lit/pdf/slaz440

    According to the errata text, when this erroneous (non-existent) ISR is called, you just have to service it to keep it from causing problems like a normal unserviced ISR would cause. But there is no flag to clear and the ISR shouldn't be called again until the timing to cause the errata (an automatic flag clearing event of certain interrupts being in a critical 6 CPU clock cycle window after a USCI interrupt occurs but before it has been serviced) lines up again.

    Regards,

    Katie

     

     

**Attention** This is a public forum