Debug Build failure

[SeeCwriter]

Well, now that you mention it, no example "says" to add #define _DEBUG. They just show wrapping calls to debug functions like InitializeNetworkGDB() in #ifdef _DEBUG. And it seemed to me one would be needed. Is that a problem? Even if I duplicated an already defined parameter, it's still defined. Plus, there was no compiler warning about a duplicate define.

Steve

[SeeCwriter]

I should have also added that, in my latest version of the example program SPISerial, I have commented out all code, including #define _DEBUG, and the #ifdef _DEBUG that wrapped InitializeNetworkGDB(). Made no difference. Or rather, it made it worse. With code in place the program would compile, link, and run, for a Release build. Now it won't even link.

Steve

[rnixon]

Did you try removing it to see if it will get rid of the error? My guess is you have the project set up to build in release mode, which will not link the debug libs, but since you added that #define your app is trying to link it.

[SeeCwriter]

Yes, as I stated in my previous post. Removing it makes no difference.

Steve

[rnixon]

Ok, so here is what does not make sense to me. You have a running example you created based on the debug eclipse guide section. Everything links and runs, correct? Somehow what you did to your app and project must be different. No other possible explanation.

As a test I added your #define _DEBUG to my code and it generated the exact error messages you mention, so there is an inconsistency there as well since when you take it out they don't go away. Maybe create a new project based on the eclipse example, get debug working correctly, then import your code into that same project, add the correct debug calls and includes, and see if that works. I think you may have an incorrect setting somewhere.

[joepasquariello]

SeeCWriter,

You said you did a "make clean" and a "make". You should also do a "make debug". The plain "make" does not build the debug libraries.

I have never been successful building libraries through the IDE, and I haven't taken the time to figure out what's wrong, so I just do it from the command line.

Joe

[rnixon]

Hi Joe,

I noticed that I had to left click to select my platform in the project manager before doing the nbeclipse->rebuild all system libraries. That is how it knows what platform to build for (since you have have multiple platforms installed).

[SeeCwriter]

Rebuilding the system directories from the commandline and doing "make debug" followed by "make" solved the linker error I was getting. The SPISerial example program now compiles and runs for both the Release and Debug builds.

However, I am still unable to single-step in the Debug build. When I single-step, the thread status changes to "stepping", and all she wrote. All the debug buttons go grey, except for Terminate and stay that way forever. And I still get the same two error messages as before when I hit the Terminate button.

This is a copy-paste of the SPISerial program as I now have it. It's stripped down to blinking one led.

Code: Select all

#include "predef.h"
#include <stdio.h>
#include <ctype.h>
#include <string.h>
#include <startnet.h>
#include <autoupdate.h>
#include <dhcpclient.h>
#include <taskmon.h>
#include <smarttrap.h>
#include <NetworkDebug.h>
#include <serial.h>
#include <pins.h>
#include <dspi.h>
// Instruct the C++ compiler not to mangle the function name
extern "C"
{
void UserMain( void * pd);
}

// Name for development tools to identify this application
const char * AppName="DSPI2Serial";

// Main task
void UserMain( void * pd)
{
    InitializeStack();
    if (EthernetIP==0) GetDHCPAddress();
//#ifdef _DEBUG
    InitializeNetworkGDB_and_Wait();
    //InitializeNetworkGDB();
//#endif
    OSChangePrio( MAIN_PRIO );
    EnableAutoUpdate();
    EnableTaskMonitor();
    EnableSmartTraps();

    SerialClose(1);
    int fdSerial = SimpleOpenSerial( 1, 115200 );
    ReplaceStdio( 0, fdSerial );	// stdin via UART 1
    ReplaceStdio( 1, fdSerial );	// stdout via UART 1
    ReplaceStdio( 2, fdSerial );	// stderr via UART 1

    iprintf( "%s application started\r\n", AppName );

    // Initialize pins needed for DSPI
#ifdef NANO54415
    //Pins[15].function(PIN_15_DSPI1_PCS0);
  	//Pins[37].function(PIN_37_DSPI1_PCS1); 	// SPI Chip-Select 1
  	//Pins[39].function(PIN_39_DSPI1_PCS2); 	// SPI Chip-Select 2
    Pins[15].function(PIN_15_GPIO);
  	Pins[37].function(PIN_37_GPIO); 	// SPI Chip-Select 1
  	Pins[39].function(PIN_39_GPIO); 	// SPI Chip-Select 2
  	Pins[31].function(PIN_31_DSPI1_SCK);
    Pins[33].function(PIN_33_DSPI1_SIN);
    Pins[35].function(PIN_35_DSPI1_SOUT);
#elif defined MOD5441X
    //    J2[30].function(PINJ2_30_DSPI1_PCS0);
    J2[25].function(PINJ2_25_DSPI1_SCK);
    J2[27].function(PINJ2_27_DSPI1_SIN);
    J2[28].function(PINJ2_28_DSPI1_SOUT);
#endif

    BYTE nCount = 0;

    while ( 1 )
    {
          OSTimeDly( TICKS_PER_SECOND );
          if (nCount++ & 0x01)	Pins[19] = 1; // LED2
          else					Pins[19] = 0;
    }
}

[SeeCwriter]

A new development. After the debugger crashed as I explained in my previous post, the dev kit board has dropped off the network. I can't ping it. Eclipse can't find it. IPSetup can't find it. I've power-cycled the board, closed and restarted Eclispe, and nothing. And the link light is blinking away on the Ethernet connector as it normally does.

Steve

[SeeCwriter]

Using the serial port I loaded another example program that has always worked, LedBinaryCounter, and now the board is back alive. I'm bailing on the debug issue. It's clear to me no one really knows anything about debug, and I've wasted most of week trying to get a simple example program to run in debug mode. It's back to prinf() statements.

I do appreciate all the help that each of you have extended. Thank you.
Steve