CCS/MSP430FR5994: Debug will not step into ISR; vectors to isr_trap when run

Part Number: MSP430FR5994

Tool/software: Code Composer Studio

I am trying to get a simple Timer A0 ISR to fire every 2 ms using the DCO clock.  I run into two problems when I debug this in CCSv8.  First, single stepping the code after the interrupt condition has been met (TA0CCTL0.CCIFG = 1 and TA0CTL.TAIFG = 1) never sends execution into the ISR even with the GIE =1.  But when I allow the code to run from this point, it enters the isr_trap.asm routine, which would seem to indicate there is something wrong with the ISR vectoring.  Since I cannot reproduce the vectoring into the isr_trap.asm by single stepping, I'm stuck.  Any clues for the source of these problems (they are probably related) would be welcome.  Thx!  Code is below, and I am using the MSP-EXP430FR5994 LaunchPad.  

    // Project Name:  TA0InterruptTest

#include <msp430.h>

    /* GLOBAL VARIABLE AND CONSTANT INITIALIZATION */
    static unsigned int count = 0;     // counter for ISR loops

    /* FUNCTION DEFINTIONS */
    /* Initialize GPIO */
void Init_GPIO(void)
{
    // initialize port bits on the LaunchPad board
    P1DIR  |= BIT1 | BIT0;      // setup P1.0 and P1.1 as outputs for the on board red and green LEDs
    P1OUT  &= ~(BIT1 | BIT0);   // start with both LEDs off
    P4DIR  |= BIT1;             // setup P4.1 as diagnostic bit for ISR from TA0
    PM5CTL0 &= ~LOCKLPM5;       // clear the LPM5 lock bit to release I/O pins from high-Z state
}

    /* Initialize Clock System */
void Init_Clock(void)
{
    CSCTL0_H = CSKEY_H;         // unlock CS registers by writing password 0xA5 to upper byte
    CSCTL1 = DCOFSEL_0;         // set DCORSEL = 0, DCOFSEL = 000b, for 1 MHz output (approximately)
    CSCTL2 = SELA__VLOCLK | SELS__DCOCLK | SELM__DCOCLK;    // set ACLK = VLOCLK, SMCLK = DCOCLK, and MCLK = DCOCLK
    CSCTL0_H = 0;               // relock CS registers by writing incorrect password (zero)
}

    /* Timer TAO Initialization */
void Init_TA0(void)
{
    TA0CCR0 = 2000-1;           // set period to 2000 counts:  2.00 ms period, 500 Hz
    TA0CCTL0 = CCIE;            // set interrupt enable for TA0CCR0
    TA0CTL = TASSEL__SMCLK | MC__UP | TACLR | TAIE; // set source to SMCLK, count up, initially clear the TCR, enable interrupt
}

/* Timer TA0 ISR */
#pragma vector = TIMER0_A0_VECTOR
__interrupt void Timer0_A0_ISR (void)   // timer TA0 fires every 2.00 ms; ISR triggers at a 500 Hz rate
{
    P4OUT ^= BIT1;              // toggle P4.1; this should produce a 250 Hz square wave diagnostic output for scope triggering
    count++;                    // increment loop counter
    if(count == 500)            // should occur with a period of 500 x 2.0 ms = 1.000 second (1.00 Hz)
    {
        P1OUT ^= BIT1;          // toggle P1.1 green LED
        count = 0;              // reset counter
    }
}

    /* MAIN PROGRAM BODY */
    /* main.c */
int main(void)
{
    /* HARDWARE INITIALIZATION */
	WDTCTL = WDTPW | WDTHOLD;	// stop watchdog timer

	Init_GPIO();                // initialize the GPIO pins
	Init_Clock();               // initialize the Clock System
	Init_TA0();                 // initialize Timer TA0

	__enable_interrupt();       // enable global interrupts
	__no_operation();           //

	/* MAIN LOOP */
	while(1)
	{
	    P1OUT ^= BIT0;          // toggle P1.0 red LED
	    __delay_cycles(10000);  // buy time
	}
}


7 Replies

  • The program is entering the isr_trap.asm routine due to the following statement setting the TAIE bit which enables the "Timer overflow" interrupt, but there is no TIMER0_A1_VECTOR handler installed:

        TA0CTL = TASSEL__SMCLK | MC__UP | TACLR | TAIE; // set source to SMCLK, count up, initially clear the TCR, enable interrupt

    Removing the setting of the TAIE bit from the above statement then allows the program to run without entering the isr_trap.asm function.

    I found this by looking at the value of the TA0IV register when the program had entered the isr_trap.asm function, since the TA0IV had the value 0Eh which meant that a "Timer overflow" interrupt was pending.

  • In reply to Chester Gillon:

    Thanks so much! That fixes the issue with the code vectoring into the isr_trap.asm function. I see now that only the CCIE bit needs to be set for the TIMER0_A0_VECTOR. I had noticed the TA0IV value of 0Eh, but did not know how to interpret that. The code works fine now.

    But single stepping in debug still does not vector into the ISR, while hitting resume does. Is this normal behavior in CCS8?

    Thanks!
  • In reply to Robert Bruce Darling:

    Robert Bruce Darling
    I had noticed the TA0IV value of 0Eh, but did not know how to interpret that.

    I used Table 25-8. TAxIV Register Description in the MSP430FR58xx, MSP430FR59xx, and MSP430FR6xx Family User's Guide to decode the value.

    Robert Bruce Darling
    But single stepping in debug still does not vector into the ISR, while hitting resume does. Is this normal behavior in CCS8?

    With this example program and CCS 8.1 I can repeat that, in that when single stepping the Timer0_A0_ISR is never entered (watching the TA0CCTL0 register in the debugger showed that the CCIFG interrupt flag had been set while stepping).

    The CCS Program/Memory Load Options has options to disable interrupts when stepping, but those options weren't ticked. Hopefully someone from TI will respond about if this is normal behaviour.

    [I vaguely remember being able to step into MSP430 ISRs in the past, but can't remember the exact CCS version and device]

  • In reply to Chester Gillon:

    Thanks for verifying, and I really appreciate your help! Also, in my case, the options to disable interrupts when stepping were NOT checked.

    I've seen various references to being able to step into ISRs, but not enough detail was given to know how universally this can be done.

    I can see the difficulty in trying to implement this smoothly within a debugger, but it would be really nice if it could single step through the interrupt process. Maybe a TI-er can chime in on this.

    Thanks much!
  • In reply to Chester Gillon:

    Chester Gillon
    I vaguely remember being able to step into MSP430 ISRs in the past, but can't remember the exact CCS version and device

    This example running in a MSP-EXP430FR5994 was tested in different CCS versions running under Ubuntu:

    1) CCS 8.1.0.00011 with the following doesn't step into the Timer0_A0_ISR:
    - TI Emulators 8.0.27.9
    - Debug Server 8.1.0.1300
    - MSP Debug Probe drivers 8.1.1, with MSPDebugStack 3.13.0.1

    2) CCS 7.4.0.00015 with the following doesn't step into the Timer0_A0_ISR:
    - TI Emulators 7.0.100.1
    - Debug Server 7.4.0.1152
    - MSP Debug Probe drivers 7.4.0, with MSPDebugStack 3.11.0.1

    3) CCS 7.3.0.00019 with the following does step into the Timer0_A0_ISR:
    - TI Emulators 8.0.27.9
    - Debug Server 7.3.0.1031
    - MSP Debug Probe drivers 7.4.0, with MSPDebugStack 3.11.0.1

    Therefore, there has been a change in behaviour between CCS versions.

    Note that the MSP-EXP430FR5994 eZ-FET firmware was left at that programmed by CCS 8.1.0, and when starting CCS 7.x selected "Ignore" on the dialogue asking if to (downgrade) the firmware.  

    The CCS project used is attached. An extra __delay_cycles(1900) has been added prior to the interrupts being enabled, so don't have to step the while loop for very many steps before the first Timer ISR should trigger (as indicated by watching the Timer A0 registers). MSP430FR5994_timer.zip

  • In reply to Chester Gillon:

    I found another quirk with CCS 8.1.0.00011 using the example attached to the previous post.

    The Tools -> GEL Files menu was used to open the view which gets to the MSP43x Debugger Options (amongst others). If the "Memory Map" is is on view when start the debug session with CCS 8.1.0 then main is reached as expected:

    If use "Step Info (F5)" then get a "MSP430: Can't Single Step Target Program: Could not single step device" error and program is then shown at the reset vector:

    Notes:

    a) The problem in CCS 8.1.0 seems sensitive to having the "Memory Map" view on display, since if the view is not open the "MSP430: Can't Single Step Target Program: Could not single step device" error isn't display and the program steps (albeit doesn't step into the Timer0_A0_ISR as mentioned above). 

    b) I can't repeat this problem using CCS 7.3.0 or 7.4.0.

  • In reply to Chester Gillon:

    Chester Gillon
    This example running in a MSP-EXP430FR5994 was tested in different CCS versions running under Ubuntu

    With CCS 8.1.0.00011 running under Windows 10 can repeat the same symptoms:

    a) Can't step into an ISR.

    b) If the Memory Map is on view when starting a debug session, the first step appears to reset the device. By looking at the registers it appears the unwanted reset is caused by "RSTNMI":