NetBurner Community Forum

You said that examples ran on the nano using the dev board, but on your own hardware you encounter the errors.
Could it be bus contention or perhaps a power issue? Either could cause the behaviour you are describing.

The examples run on my hardware as well. Part of my problem was that v2.7.0 does not work the same as prior versions.
In prior versions, when a debug build was downloaded, Eclipse would automatically switch to debug mode. But v2.7.0
does not do that. After the download you have to click on the "Debug" button on second row of icons to get into debug mode.
The next problem is that, unlike every other debugger I've used, after the program is downloaded it doesn't stop at the
beginning of usermain() or even at InitializeNetworkGDB_and_Wait() and wait for the user to issue debug commands
like "step" so I can step through the program and find where it's going off the rails. Instead, it loads and runs and crashes
before I can do anything to stop it.

You can get the debugger to stop at a point in the program:
click the down arrow beside the bug icon,
click "Debug Configurations" {while you are there, make sure the IP address is correct}
click the "Debugger" tab
check the "Stop on startup at" box. {I think you can change "main" to some other function.}
While you are at this point, click on the "Connection" tab in the "Debugger Options" window and make sure that the IP address is the same as the one under "Debug Configurations". The "Type" should be "TCP" and the Port should be "2159".

If the IP address under Debugger Options is blank or different than the one for the Module, you will get the kind of error you described: "Target execution failed" and "Target actively refused the connection".


As for Eclipse changing the perspective to Debug with the Debugger launches, there is a setting in
Window->Preferences->Run/Debug->Perspectives "Open the associated perspective when launching" that controls the behavior, I think. Even with that set to "Always", if the launch fails, the perspective might not open.

The first time you run the debugger a dialog box comes up with a checkbox that asks if you want eclipse to always automatically change the perspective. If you don't select it, then its manual, or as ecasey said, change it in the preferences. I have upgraded many many times, and that dialog box always comes up. You might have just missed it somehow.

One other trick I use for any gdb debugger is to add a "char c = getchar()" in my code after I get my IP address and after the init debugger call. I had downloaded a crashing application, and this allowed me to download new code over the network connection instead of having to use serial. Just make sure you put it after the point you get an IP address otherwise the downloads won't work. Or, if you get tired of hitting the enter key in mttty each time to get past that point, I suppose you could put in a delay big enough to get a download started, like OSTimeDly(TICKS_PER_SECOND * 10).

It seems that there is yet a third place you have to enter the IP address of the target board for debug mode that was not
set. Hence the failure to run in debug mode. I seem to recall running into this same issue when I was playing around with
the dev kit about 3-months ago.

In any case, I am now able to run in debug mode. And the use of getchar() to stop the program after init is exactly what I
needed. Thanks for that excellent tip.

Thanks.

This seems to be a common problem, and I have not seen a single reply by Netburner personnel related to this issue. I am trying to get a coworker up and running to modify an application I developed (without the use of the debugger in recent years). He is getting the same "target failed to respond' error as others are describing. It works with one of the supplied apps that comes with the dev board, but not with my app. It fails with both v2.7.1 and 2.7.4.

We have:

1) Ensured the IP address is set correctly in every place we could find.
2) Added the -DEBUG define and made the call to the InitGDBServer() (also tried the _and_Wait version).

When we run the debugger, the code loads and begins running while the debugger is still supposedly launching (at 44%). Our code is already running when the launching moves to 87%, and then produces the taget failed to respond error. These problems cost us a lot of money, and it seems that every time there is a new release, new problems pop up.

I quickly learned that I spend more more time fighting with these tools than I do with just building in release mode and skipping the debugger, so I haven't used it in a long time. I am ready to design the Netburner out of our products I can secure funding to do so. Netburner, you have one more chance to convince me to stick with you. Tell us what the hell is going on with the debugger. At least give us some clues as to where to look.

If it works with the examples, but not with your code, then the first thing I would do is reduce the number of variables. Take a look at the working example, then add a while(1) loop with a time delay in your code sometime after the init gdb call, just as the example does. Move this loop down through your code until a problem occurs and that may tell you what it incompatible in your code. The only way to have it be almost code independent is to have a hardware debugger instead of a software gdb debugger. But the debugger has always worked fine for me. Although I prefer release mode during development because debug builds on any system do not represent the code I will be shipping, since optimization has to be turned off.

GDB software debuggers rely on a GDB stub running on the target platform, and like any software it will need some resources to run. I'm not a debugger expert, but I think it uses IRQ 7 non maskable. If your code is using that as well there may be a conflict.

Other things I have learned:
There are multiple places where the IP addresses need to be set, because it is possible for the target to have a different IP than the debugger connection. I always make them the same though. There are 2 essential places: the run configuration tab, and the debug connection tab for the debugger.

"localhost:2159: No connection could be made because the target machine actively refused it." is telling you that you did not set an IP address in the debug configuration connection tab. There has to be a default, so its localhost on port 2159, which is your pc, not the target. Since you pc isn't running a target gdb stub listening on port 2159 it throws a standard TCP error message saying the connection was actively refused (which I think is a RST). You will also get an active refusal message if there is not a call to init the gdb stub. I copied this error message from a prior post in this thread. Just glossing over it, it seem the problem was that the debugger IP address was not set, and that the checkbox to automatically switch perspectives was not enabled.

Anti virus and firewalls have blocked my connection at times, since a network connection needs to be established from the pc to the device. Thats an issue with my firewall, not GDB.