ADC10 Interrupt Handler “user provided function name” Results In Error

Hi Juan,

as Dave pointed out already you need to write your interrupt service routine by yourself. So, let's assume you have a ISR like the example below in your code

/*
 *  ======== button_push_isr ========
 *  GPIO Port 1 ISR
 *
 *  This ISR handles the button push and uses the WDT
 *  to efficiently manage delays for debounce.
 *
 *  This interrupt handler routine (for GPIO port 1) gets
 *  assigned in the GPIO Grace view.
 */
void button_push_isr(void)
{
    P1IFG &= ~BIT3;                   // Clear the port 1.3 interrupt flag
    P1IE &= ~BIT3;                    // Disable this (GPIO P1.3) interrupt 

    /* Use WDT as an interval counter for button debounce */
    IFG1 &= ~WDTIFG;                  // Clear any pre-existing WDT interrupt
    WDTCTL = (WDTCTL & 7) + WDTCNTCL  // Reset watchdog with same divider,
        + WDTPW + WDTTMSEL;           // write password, and timer mode
    IE1 |= WDTIE;                     // Enable WDT interrupts

    if (buttonOn == 1) {              // Switch LED and button state
        buttonOn = 0;
        P1OUT &= ~BIT0;
    }
    else {
        buttonOn = 1;
        P1OUT |= BIT0;
    }
}

This is the ISR for the Port 1 interrupt (P1.3 in this example).
So, now you need to provide the ISR-function name to Grace. The ISR fuunction name for this example is button_push_isr

Resulting from the above, your Grace GPIO window looks like below.

Rgds
aBUGSworstnightmare

P.S. By the way: The code is from the Grace button debounce example

David,  Your answer sounds reasonable, since that is what I was expecting. I had done a project w/ CodeWarrior that does exactly that. It autogenerates all basic peripheral ISRs, such as an interrupt on a timer expiring, etc, and it additionally inserts a stub call to what they call a user event (but more in spirit of a callback), all user events of which are placed in event.c.  

I did realize the ISR code was not there, so I created the code after my function’s name symbol was not resolved. However, that did not completely work, since then it complained about not being able to find the (.h) file.

My best guess is that the path for my header include file is still not being properly set.  

But your answer should be correct. There is something missing in my environment’s configuration. I added the header file by using the “Add Header File” menu option, but then it couldn’t see the header file.  

aBUGSworstnightmare, your answer is also reasonable, and it should be also correct. However, like I said in my answer to David, there is something not properly set in my environment's configuration, keeping my code from linking.  

I’ll keep on it. When I figure out what’s wrong, I’ll post here for completion.  

Ok, so I was getting the error: “could not open source file “App.h”.   I right-clicked on the file and selected <Properties> and saw that I was probably missing part of the path in my #include statement. So I went back and included the fuller path in both “main.c” and “App.c”, such as “#include <src/App.h”. myISR is declared “extern” in the .h file, and defined (as a stub) in “App.c”. Recompiled, and now the error changes to, “unresolved symbol myISR, first referenced in C:\DOCUME~\USERNAME~\MYDOCU~1\CCS\myApp\src\csl/csl.lib<CSL_init.obj>”.  

Also note that I have checked _x_ Enable Analog to Digital Converter Interrupt, Interrupt Handler: myISR, After Interrupt: Do Not Change Operating Mode.  

So I went into “CSL_init.c”, and it contains a declaration “extern void myISR(void);”, just as in my .h file. In addition, inside “__interrupt void ADC10_ISR_HOOK(void) { /* ADC10 Interrupt Handler */ myISR(); }”, there is a call to my routine. Ok, so everything seems to be there, in the right place, but it will not link, and the error is (still),  

Unresolved symbol myISR, first referenced in the “…/csl.lib<CSL_init.obj>”.  

So, this better describes the situation (w/ a bit more detail). Now the question is, “What am I missing?”.  

Ok, so I searched the error output listing to see if my source file was there, and I couldn’t find it. All other .c files are there. However, my “App.c” does not seem to be compiled, and thus is not being linked with the rest of source modules. Again, I added this file by utilizing a menu option, such as “Add Source File”, but for whatever reason, my App’s source code is not being compiled, and linked, and thus, that is probably why the ISR’s function is referenced first (and last) in “CSL_init.c”, but nowhere to be found – it does not exist, as far as the linker is concerned. I think I am getting closer…

Hi,

1.) create a header file, i.e. button.h
Grace will open a new file which looks like

#ifndef BUTTON_H_
#define BUTTON_H_

#endif /*BUTTON_H_*/

2.) add at least the two inludes below too your header to make it then look like

#ifndef BUTTON_H_
#define BUTTON_H_

/*
 * ======== Standard MSP430 includes ========
 */
#include <msp430.h>

/*
 * ======== Grace related includes ========
 */
#include <ti/mcu/msp430/csl/CSL.h>

#endif /*BUTTON_H_*/

3.) for my example above you need to add two more lines with for the ISR function and the variable used by the function. Now your header looks like

#ifndef BUTTON_H_
#define BUTTON_H_

/*
 * ======== Standard MSP430 includes ========
 */
#include <msp430.h>

/*
 * ======== Grace related includes ========
 */
#include <ti/mcu/msp430/csl/CSL.h>

extern void button_push_isr(void);

extern unsigned char buttonOn;

#endif /*BUTTON_H_*/

4.) comment out those Standard MSP430 and Grace related includes in your main file and add your new header instead
/*
 * ======== Standard MSP430 includes ========
 */
//#include <msp430.h>

/*
 * ======== Grace related includes ========
 */
//#include <ti/mcu/msp430/csl/CSL.h>

// include my new header instead
#include "button.h"

5.) create an new C file with your ISR routine and include the new header too, like:
#include "button.h"

/*
 *  ======== button_push_isr ========
 *  GPIO Port 1 ISR
 *
 *  This ISR handles the button push and uses the WDT
 *  to efficiently manage delays for debounce.
 *
 *  This interrupt handler routine (for GPIO port 1) gets
 *  assigned in the GPIO Grace view.
 */
void button_push_isr(void)
{
    P1IFG &= ~BIT3;                   // Clear the port 1.3 interrupt flag
    P1IE &= ~BIT3;                    // Disable this (GPIO P1.3) interrupt 

    /* Use WDT as an interval counter for button debounce */
    IFG1 &= ~WDTIFG;                  // Clear any pre-existing WDT interrupt
    WDTCTL = (WDTCTL & 7) + WDTCNTCL  // Reset watchdog with same divider,
        + WDTPW + WDTTMSEL;           // write password, and timer mode
    IE1 |= WDTIE;                     // Enable WDT interrupts

    if (buttonOn == 1) {              // Switch LED and button state
        buttonOn = 0;
        P1OUT &= ~BIT0;
    }
    else {
        buttonOn = 1;
        P1OUT |= BIT0;
    }
}

6.) You must include your new header to all your C source files too!
7.) Compile your application

Rgds
aBUGSworstnightmare

P.S. Try to repeat the steps described above with the Pushbotton example from Grace. You can access it by creating a new Grace project and select the Grace example from the menue instead of an 'empty Grace Project'

I did what you suggested (w/ the header #include statements), but now I get 2 identical error entries (instead of just 1), reading,  

could not open source file "App.h"  

could not open source file "App.h"  

I don’t understand why Grace can’t see just 1 file added and included with its own menu. I am getting frustrated here… I got to move on, but I can’t move on. I can’t even find an explanation for the error – there is no real help file available covering Grace issues.  

Juan Mustelier said:

Ok, so I searched the error output listing to see if my source file was there, and I couldn’t find it. All other .c files are there. However, my “App.c” does not seem to be compiled, and thus is not being linked with the rest of source modules. Again, I added this file by utilizing a menu option, such as “Add Source File”, but for whatever reason, my App’s source code is not being compiled, and linked, and thus, that is probably why the ISR’s function is referenced first (and last) in “CSL_init.c”, but nowhere to be found – it does not exist, as far as the linker is concerned. I think I am getting closer…

If you put App.c (or App.h) in the Grace generated ./src sub-directory, these files will  be _excluded_ from the "normal" project compile and link steps.  This might explain what you are seeing.

Try placing your application sources in the "base" directory of the project or any sub-directory that you create by hand.

The _only_ source files in the ./src sub-directory that are compiled are those generated by Grace; ./src is created by Grace for generated files only.

Although I’ve had them on other folders before, at one point I decided to start from scratch, and I did. I deleted the project (via menu), including deleting all of the files. I started a basic Grace empty project. Selected the “MSP430F2122” device. In the configuration I enabled reading multiple A/D channels. I enabled the interrupt, and gave it a “Handler” name. I added a source file, and a header file – just as you would normally do in any other C environment, w/ the includes in all of the appropriate places. So both the source and header files are currently residing at the root directory of my project, such as “CCS/ProjectName/”. But no, I still get the error “could not open source file “App.h”. Is there a setting where you should specify this directory, or does it look there by default? I mean, the files are placed, in the GUI, right above “main.c”. When I right-click and select <Properties>, the pop-up window shows the right path, where the files are located. Everything seems to be there, in the right place, but the error remains.

Juan Mustelier said:

Now the trick is in the #include statement. Notice the two dots preceding the header’s file name (not obvious to me),

  

#include <../App.h>

The problem is that files included via <>'s are _only_ found along the paths specified by -I options passed to the compiler.  If you use "'s instead, you do not need to use ../App.h.

This is because the C pre-processor treats files in "'s differently from files in <>'s:  files in "'s are _first_ searched for in the directory containing the file that has the #include statement (in your case App.c) and, if it's not found, it then looks in the directories named by -I options passed to the compiler. 

Alternatively, you can change your project compiler options to include "-I..".

You can see/modify your project compiler options by right-clicking on your project and selecting Build Properties->MSP430 Compiler->Include Options.

BTW: the reason for ".." is that the current working directory for the build is the ./Debug (or ./Release) sub-directory of the project.

The thing is that as a RAD (Rapid Application Development) user, shouldn’t the tool know these things (whatever happens underneath the covers) and modify the Makefile automatically for you, as you change from Debug to Release versions of the code, and so that “you” don’t have to worry about these (sometimes many) cryptic details ??? Thanks.

Juan Mustelier said:

The thing is that as a RAD (Rapid Application Development) user, shouldn’t the tool know these things (whatever happens underneath the covers) and modify the Makefile automatically for you, as you change from Debug to Release versions of the code, and so that “you” don’t have to worry about these (sometimes many) cryptic details ??? Thanks.

I tend to agree.  This behavior is not Grace-specific, however.  It's how _all_ CCS 4.2.1 C projects are handled. 

That said, it is possible for Grace projects to automatically add -I.. to the project's compile options.  The problem comes when people want to add Grace to existing C projects: implicitly adding "-I../" runs the risk of breaking the existing C project.