MSP430FR2355: Variable not counting in application --- Declared in library......

The isr_trap symptom suggests that the ISR isn't actually being linked. Does its name appear in the .map file? From this snippet it's hard to tell who's incrementing the variable.

Linking an ISR from a library is a knotty problem, since there's no explicit reference to it in the main .o file. I fought with this some years ago (pre-dates CCS) and I don't recall finding a good solution.

You might be able to force it by putting a dummy reference to the ISR name in the user-callable function, or by adding a linker option like "--undef_sym=T2_B0" [ref Asm430 User Guide (SLAU131V) Sec 8.4.31]

Hi Steve,

Beyond Bruce said, you can try to add a break point in the ISR code. If you can not add the break point then it should be the link issue.

Best regards,

Cash Hao

By all indications I believe it is in the .map file....See below from map file...Notice T2_B0 and RF_ISR existence:

.text:_isr
* 0 00008a14 0000003e
00008a14 00000020 rts430x_lc_sd_eabi.lib : boot.c.obj (.text:_isr:_c_int00_noargs_mpu)
00008a34 0000000c LPRS_lib.lib : lprs_mspConfig.obj (.text:_isr:T2_B0)
00008a40 0000000a : lprs_mspConfig.obj (.text:_isr:RF_ISR)
00008a4a 00000008 rts430x_lc_sd_eabi.lib : isr_trap.asm.obj (.text:_isr:__TI_ISR_TRAP)

The variable is being incremented within the ISR that is in the library project c file.  The ONLY thing main.c (in another project) will do is zero out the variable at startup and then look at the value periodically and make decisions based upon that value.

I added this option to the main application code (I assumed here that you did not mean the library project) but I still cannot break within the ISR.  As mentioned the map file for the main application does show the T2_B0 object.

Bruce....

More information....

I load application onto a target and go to Memory Browser in CCS.  I can see that the ISR Vector address FFF0 is pointing 8a3a.  .map file confirms that 8a3a is T0_B2.  datasheet confirms FFF0 is Timer2 B0.  All looks good, yet still I jump into TI ISR trap.  Do you have any more thoughts here?

Steve

OK, there goes that hypothesis. One reason for looking there first, besides Proximity, is that checking it (as you have) is pretty easy. Unfortunately the MSP430 doesn't provide an indicator of what interrupt was last triggered.

The next step would probably be to audit your code for stray IE settings (including typos). It looks like your code isn't too large, so maybe that's tractable?

The "correct" way to catch this is to define a separate ISR for each possible interrupt (24-1 in all). The ISRs needn't do anything, you'll be able to tell what happened from the function name. This is tedious and time-consuming, so I usually first walk through the Registers view looking for suspects.

I completely took everything out of the c library file except:

#include <msp430.h>
#include "lprs_mspConfig.h"
#include "stdlib.h"
#include "string.h"
#include "stdio.h"


#ifdef TIMERB0
#pragma vector = TIMER2_B0_VECTOR
__interrupt void T2_B0(void)
{
    timer2b0_ISR_cntr++;
    LPM3_EXIT;
}
#endif

My c application code (this exists in a 2nd project that is executable) is stripped down:

#include <msp430.h>
#include "application.h"
#include "lprs_mspConfig.h"
#include "string.h"
#include "math.h"

volatile uint timer2b0_ISR_cntr = 0;

int main(void)
{

    WDTCTL = WDTPW | WDTHOLD;   // stop watchdog timer

    TB0CCR0 = 4555;
    TB0CTL = TBSSEL__ACLK;
    TB0CCTL0 &= ~CCIFG;
    TB0R = 0;
    TB0CCTL0 |= CCIE;
    TB0CTL |= MC__UP;

    while (1) {
        __bis_SR_register(LPM3_bits + GIE);
        if (timer2b0_ISR_cntr >= 10)
            timer2b0_ISR_cntr = 0;
    }
}

The header library file (lprs_mspConfig.h):

#define TIMERB0

typedef unsigned int uint;

#ifdef TIMERB0
extern volatile uint timer2b0_ISR_cntr;
#endif

The map file looks good (ie shows existence of T2_B0.  I am still jumping into TI ISR trap.  The application.h in the executable project is empty.  The processor I am targeting is MSP430F2355.

I am not sure why this doesn't work (the code doesn't get any simpler) and really not sure what to try at this end....There are NO other ISRs and watchdog is disabled.   Ideas?

Ughhhhhh!!!!!!!!  

Thank you!!!

Stupid, stupid mistake!  Deep in the forest you just never see the trees....

Once again thanks for all the help

Steve