Unresolved breakpoints in debugger

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Not applicable
I have noticed that the debugger will allow you to load a firmware build that has been configured, and compiled, for release, instead of debug. This results in a condition where the debugger may be running, but the variables can't be evaluated, and breakpoints are inoperable. The debugger behavior is not what's expected, and there is no clear indication of why. The first thing I noticed, was that when creating breakpoints, they are unresolved. I'd like to recommend that the software team add a warning message to let the user know if they are attempting to load the debugger with a build configured for release, and what the consequences are. This is one of my first experiences with the tool and I spent some time trying to understand why my breakpoints were unresolved, and unusable. Adding a warning, would make the tool more user friendly to those of us getting our feet wet with DAVE, especially when we are starting with example projects that we know should work. I really like the parts, and what you are doing with DAVE. Keep up the good work!
0 Likes
3 Replies
Not applicable
Dear Robiwan,

I have this problem with my project.
I have two examples, in one example I am able to set break point but in another one no! 😞
The point I could not understand is that when I change the workspace situation changes and I am not able to set breakpoint in both projects!
in both cases I have set the project in Debug mode not release.

I will really appreciate if someone can help me.

best regards,
0 Likes
WoS
Employee
Employee
First solution authored
Just setting "debug" as build configuration gives you a bunch of settings related to this configuration - but you can set/change them to whatever you want, even to generate code w/o debugging in.
This "Debug" and "Release" text you can see in the project explorer just names for this configurations. This is a quite common topic of such IDE environments (here it is an Eclipse feature), not very Dave/XMC specific. I am using Eclipse also (and more often) for other code development than cross-compile to XMC/ARM.

When setting up a default project with DAVE, usually all debug flags are initially set in the "Debug" configuration and removed in the "Release" configuration. But you can make your own build configuration with any name you like. Eclipse does not care, so to say (any Eclipse developer please correct me, if I am wrong here).

Within a debug configuration, you can also set optimization settings of the compiler as well (if you set up a new default project these are set to "-O0 (none)" for the debug build as far as I know).

But if it is set to something else than "-O0", the compiler may optimize redundant code parts away, thus you may not be able to set breakpoints there anymore.

So to check this, you may look at least here
Right click on project in project explorer -> "Properties", there you can go to "C/C++ Build" -> "Settings"
From there you can select in the "Tool Settings" tab:
"ARM-GCC C Compiler" -> "Optimization" -> "Optimization level" --> which you can set to -O0 to avoid any optimization -> slower/larger code will be the result, but you should be able to set breakpoints wherever you like
"Debugging" -> "Debug level" --> which should be on "Default (-g)" to enable the compiler to generate the additional data in the binary for debugging

Of course for naming consistency, this should be done in the "Debug" build configuration only (you can set in the project explorer -> "Build Configurations" -> "Set Active") And please don't forget to do a full rebuild, just in case... 😉
0 Likes
Not applicable
Thanks.
The problem is solved.
The problem was, even if I have done all the configurations right and I have set the debugging mode not the Release but, in J-link connection, the release configuration still was there above the debug newly added configuration.
and since it was above debug setting, device was using release mode always!
I have removed the release setting and problem is solved.
0 Likes