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.

undefined reference to `P1OUT'

Other Parts Discussed in Thread: MSP430G2955, MSP-FET

I am working on modifying software I wrote last year. All I changed was a value in an "if" statement. But now I am getting numerous errors.  The first one is  " undefined reference to `P1OUT' "  This is followed by many "undefined reference to <fill in the blank>"  I am using CCS Version: 6.1.0.00104 with the GCC compiler.  Nothing else, that I know of, in the code has changed. Is there an include file somewhere that I may have lost.  I am using the same computer and to the best of my knowledge nothing else has changed. 

  • I am using an msp430g2955.
  • Using #include "msp430.h" ?
    As the compiler will locate the correct msp430G2955.h file for you,
    but you have not set up the "new/updated" project as a G2955 yet?
  • I had set it up as a G2955.  Thank you for the answer, it worked.  I have always just added the msp450XXXXX.h files to my projects.  It has never been a problem before.  

  • I spoke too soon. The code will now compile, but is no longer functional.  I had install the updates to the software a few weeks ago.  The current msp430g2955.h is dated 2016.  I tried adding an older msp430G2955.h, dated 2013, file I found online and it compiled if I added the msp430.h, but it would not function.  I restored the current version of msp430g2955.h I get the same errors as before, and it makes no difference if the msp430.h is included or not.   

  • Create a new workspace from scratch.
    select msp for the project you will use,
    select FET and not simulator mode (probably only IAR that have simulation?)

    copy and past the old code over, compile.

  • I did that and ended up having to build a new project using the TI compiler version 4.4.6. It now compiles with no problem and the code functions properly as long as I have debug as the active state and the MSP-FET connected to my board, even if CCS is closed on my computer. If I disconnect MSP-FET and recycle power my code does not appear to be doing anything. I get the same results if I change the active state to release. Any ideas on how I can get my code to work independently of the MSP-FET.
  • 47K pull-up is missing in reset pin? (or broken, dry solder joint)
    as a tell tale sign when things work with debugger attached, as it has its own pull-up.

    If the board has backup battery/supercap for the msp, then exit debugger correctly and creating a reset (Launchpad have reset button)  

  • I had the same thought over night. Originally I had a 4.7K in the circuit. So this morning I replaced it with a 47K. The change had no effect.
  • By placing flags in my code to pulse an output. I was able to track down the point where it hangs up. My code goes through an initialization routine setting up IO ports, A/D, a timer and a UART. It then tests several functions on my board using IO and A/D. It then begins to send serial data via the UART. After every two bytes, it configures the receive interrupts and pauses (software delay) for a certain period of time to wait for a response. It then disables the interrupts and goes to the next transmission. It all behaves as expected if the debugger is connected to the board. If I disconnect it, then the code hangs up when I configure and enable the receive interrupts.


    IFG2 &= ~UCA0RXIFG; //clear RX interrupt flag
    P1IE |= RXD; //configure and enable RX interrupt <= HANGS UP AFTER THIS LINE
    IE2 |= UCA0RXIE;

    It hangs at this point consistently every time, but only if the debugger is disconnected. If it is attached, the whole code functions as required.
  • You're enabling edge interrupt on a Port pin that is used for hardware UART.
    Are you sure you want that?

    P1 ISR don't clear their IFG automatically on MSP models without port TAIV, so  the ISR gets called over and over,
    making it look like the system froze up.

  • Thanks. That appears to have fixed the problem. I just deleted the line altogether. The function I thought it was doing was to enable the receive interrupt. It is obvious that the next line did that function. Now the interesting part is, how did it function at all with the debugger attached. The code should not have worked either way.
  • The debugger (also Launchpad) have pull-up resistor on UART lines, so when attached pin did not float as without it you got random edges.

**Attention** This is a public forum