• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 2 answers
  • Subscribers 79 subscribers
  • Views 2940 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.

CCS/MSP430F2274: Program will not stop at breakpoint set in ISR

Sean Kramer
Intellectual 770 points
Part Number: MSP430F2274

Tool/software: Code Composer Studio

Trying to use a variable within the timerA ISR to delay the amount of time before exiting low-power mode and continue with the program, but when including the flag the length of time does not increase. To try and find the problem I modified the code and set a breakpoint in the ISR to see what the value was of the variable. When running this program, the debugger does not stop at the breakpoint even though the ISR has been triggered. Is there a reason for this, or can I change the settings of Code Composer to allow breakpoints with ISRs? The code I am running is listed below:

#include <msp430.h>

void configWDT(void);
void configClocks(void);
void configGPIO(void);
void configTimerA(void);

volatile int blink_cnt;
static volatile int intrp_flg;

int main(void)
{
    blink_cnt = 0;
    configWDT();
    configClocks();
    configGPIO();
    configTimerA();

    __bis_SR_register(GIE);             // Enter LPM3


    while(1)
    {
//        __bis_SR_register(GIE);             // Enter LPM3
//        if(blink_cnt)
//        {
//            P1OUT ^= BIT0;
//        }
    }
}


void configWDT(void)
{
    WDTCTL = WDTPW + WDTHOLD;
}


void configClocks()
{
    DCOCTL |= DCO1 + DCO0;
    BCSCTL1 |= XT2OFF + RSEL2 + RSEL1 + RSEL0;
    BCSCTL2 |= SELM_3 + SELS;
    BCSCTL3 |= XT2S_3;
}


void configGPIO(void)
{
    P1DIR |= 0x03;                            // P1.1 output
    P1SEL |= 0x02;                            // P1.1 option select
}


void configTimerA(void)
{
    //TACCTL0 |= OUTMOD_4;                       // TACCR0 toggle mode
    //TACCR0 |= 0xFFFF;
    TACCR0 = 0x25;
    TACTL |= TASSEL_1 + MC_1 + TAIE;    // ACLK, up-downmode
}

// Timer_A3 Interrupt Vector (TAIV) handler
#if defined(__TI_COMPILER_VERSION__) || defined(__IAR_SYSTEMS_ICC__)
#pragma vector=TIMERA1_VECTOR
__interrupt void Timer_A(void)
#elif defined(__GNUC__)
void __attribute__ ((interrupt(TIMERA1_VECTOR))) Timer_A (void)
#else
#error Compiler not supported!
#endif
{
    intrp_flg = 0;
    switch(TAIV)        // Efficient switch-implementation
    {
        case  2:
            break;                        // TACCR1 not used
        case  4:
            break;                        // TACCR2 not used
        case 10:
            P1OUT ^= BIT0;
//            if(intrp_flg % 4 == 0) {
//                //blink_cnt++;
//                //P1OUT ^= BIT0;
//                //__bic_SR_register_on_exit(LPM3_bits);
//            }
            break;
    }
    intrp_flg++;
}

The breakpoint was set at the switch(TAIV) statement and another one was set at the P1OUT ^= BIT0 statement, yet the debugger does not stop at either one.

  • 0
    Intellectual 770 points

    Part Number: MSP430F2274

    Have been trying to debug a simple example program for the MSP430F2274 device. The example uses timerA in continuous mode and toggles and LED when an interrupt occurs (a.k.a when TAIV = 10). Within the `interrupt void Timer_A(void)` function, I have set a breakpoint at a switch statement, which chooses the operation to be performed depending on the value of TAIV. When entering debug mode the program never stops at the breakpoint, making it appear that the interrupt is never reached. Upon viewing the register, I can confirm that an interrupt has occurred based upon the change in the TAIV register. Is it possible to have a breakpoint set in an interrupt function? If it is, could there be a reason as to why this it is never triggered during my debug session? If not, is there another method of debugging that confirms that the ISR is reached? Ideally, if the ISR can be stepped through it would be much more helpful for future project work using this device.

    Furthermore, once the program is run from the debugger, the intended functionality is not happening until the device is disconnected and reconnected to a power source. The problem is that when disconnecting from the USB, the debugger stops working as it no longer has a device that it can reach for its debugging purposes. Is there a reason that this occurs, or is this common with all MSP430 devices? If not, are there any options which can be changed to allow the device to work correctly once the debugger has begun running, without having to disconnect/reconnect it? 

    CODE:

    #include <msp430.h>

int main(void)
{
  WDTCTL = WDTPW + WDTHOLD;                 // Stop WDT
  P1DIR |= 0x01;                            // P1.0 output

  TACTL = TASSEL_2 + MC_2 + TAIE;           // SMCLK, contmode, interrupt

  __bis_SR_register(GIE);       // Enter LPM0 w/ interrupt

  for (;;);
}

// Timer_A3 Interrupt Vector (TAIV) handler
#if defined(__TI_COMPILER_VERSION__) || defined(__IAR_SYSTEMS_ICC__)
#pragma vector=TIMERA1_VECTOR
__interrupt void Timer_A(void)
#elif defined(__GNUC__)
void __attribute__ ((interrupt(TIMERA1_VECTOR))) Timer_A (void)
#else
#error Compiler not supported!
#endif
{
  switch(TAIV)       // Efficient switch-implementation
  {
    case  2:
        break;                         // TACCR1 not used
    case  4:
        break;                         // TACCR2 not used
    case 10:
        P1OUT ^= 0x01;                 // overflow
        break;
  }
}

  • 0
    TI__Genius 10980 points
    Hi,

    How are you determining that the ISR is being triggered?

    Also, for you first breakpoint, nothing is being executed in that line of code, so it is possible that CCS is not allowing the breakpoint to be set there. Please try moving that breakpoint up one line and see if you see that one hit. For your second breakpoint, it is possible that you are not actually getting in that case. Please try adding a default case to your switch statement and see if that one gets hit.

    Regards,
    Nathan
  • 0 in reply to Nathan Siegel
    Intellectual 770 points
    I can confirm that the ISR is being reached when disconnecting and reconnecting the device and seeing the LED toggle, if the device is remained plugged in after clicking the "debug" and "run" icons, it will remain in the `while(1)` loop even though the TAIV register is set during the triggering of an interrupt from TimerA. The problem is that once the device is disconnected the debugger will cease to work, causing me to terminate the current debug session and begin again with the same problems.
  • 0 in reply to Sean Kramer
    TI__Genius 10980 points
    Hi,

    Can you please try moving the breakpoints, as I suggested? The first line of the switch statement is not a valid place to put a breakpoint.

    Additionally, disconnecting and reconnecting the device will reinitialize the code, which will cause the LED to toggle in your switch statement. So it is not doing it because the timer is actually working as you are intending. Are you using completely unmodified example code?

    Regards,
    Nathan
  • 0 in reply to Nathan Siegel
    Intellectual 770 points
    I moved the first breakpoint up from the switch statement to the #endif line, and put a second breakpoint in the default case, which I made it toggle the second LED on the device.

    There are slight modifications made the example code, I removed the part of `__bis_SR_register(LPM0_bits + GIE)` to `__bis_SR_register(GIE)` because the debugger will not run if the CPU is off (which happens when entering any low-power mode. Is there any method to still allow for debugging during any low-power mode? I'm assuming the answer is no, as the debugger needs the CPU to be on for any debugging functions.

    I tried running it without disconnecting/reconnecting but the DCOCLK ran at a really slow pace, making it take a while before reaching the value of 0xFFFF, which is required for triggering setting an interrupt value to the TAIV register. But still, even after running the program, neither breakpoint was reached by the debugger.
  • 0 in reply to Nathan Siegel
    Intellectual 770 points
    Could the problem be from using a eZ430-RF2500 USB-based development connection instead of something like a JTAG or other tool?
  • 0 in reply to Sean Kramer
    TI__Genius 10980 points
    Hi,

    No, you will not be able to use the debugger when in a low power mode because the CPU will be off.

    However, it looks like your problem is that you are using the interrupt vector for the wrong timer channel. You set pin 1.1 as your timer pin, but this corresponds to timer_A3. But, for your ISR, you use TIMERA1_VECTOR. This needs to be TIMERA3_VECTOR. Please make this change and make sure that you are using the datasheet and User's Guide to make sure you are setting the registers and defining your ISRs correctly.

    Regards,
    Nathan
  • 0 in reply to Nathan Siegel
    Intellectual 770 points
    from the `msp430f2274.h` file there is an interrupt vector named `TIMERA1_VECTOR`, but no `TIMERA3_VECTOR`. Also, I am able to view registers while in low-power mode. Unless something is wrong, when the running the code I can see the SR = 0xD8, so I have no idea what is going on.
  • 0 in reply to Sean Kramer
    TI__Genius 10980 points
    Hi,

    Sorry for the confusion. You should be using TIMERA0_VECTOR for that pin. Again, please see the datasheet (and User's Guide) for more information on this. Specifically, Table 21 describes this.

    Regards,
    Nathan

**Attention** This is a public forum