debugger starts in wrong code location

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

cross mob
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Currently trying to debug a CYBLE-022001 using Kitprog CY8CKIT-024-BLE.  Programming the device works fine and the checksum is verified, however when starting a debug session the debugger halts in the wrong code location (it halts in some random bluetooth handling code, which is not even called) rather than main.c.  The debugger consistently halts in the wrong place even after multiple cleans and rebuilds so I'm thinking it's using the wrong symbols or something to find out where main is?  Or it's maybe getting confused as to which source file contains main?

   

When the debugger is launched, the "Call Stack" looks OK (has main() at the top), except for the "File" column, which is showing the wrong source file (should be main.c but it's a different file, the file that it's showing doesn't even have a main() method anywhere).

   

I should note that I'm trying to re-use some code files from another project (I edited the "additional include directories" of the compiler under "Build Settings" to include a folder from another project).  Perhaps this is messing up the compilation/symbol assimilation process?  If I use one of the example projects, the debugger halts in the correct location and everything appears to work fine.  Suggestions for getting this working?  I've already tried rebooting, cleaning, rebuilding both projects, etc.

0 Likes
1 Solution
Anonymous
Not applicable

OK, so I've figured out a way to (seemingly) fix this, but it's very strange.  I took the offending file (BLEM.c in my case) and I removed it and its corresponding header BLEM.h from the project, then re-added it back in.  Rebuilt and now debugger works fine.

   

 Not sure if I ran into some weird bug in Visual Studio or something.  I'll update here if the problem reoccurs, or if I can find steps to reproduce it.

View solution in original post

0 Likes
7 Replies
himam_31
Employee
Employee
50 likes received 25 likes received 10 likes received

Hello ,

   

 

   

Can you check what is the Compiler optimization in "Build Settings"? Can you you set the optimization to "Debug" and check if you still faces the issue.

   

 

   

Thanks,

   

Hima

0 Likes
Anonymous
Not applicable

Setting the Compiler optimization to "Debug" changed things a little bit, but did not fix the overall problem.  The debugger now starts in main(), but when I try to "step into" a function call, the debugger incorrectly jumps back to the random bluetooth code.  Strangely, when I set the Compiler optimization back to "None", it now starts in main() but still incorrectly jumps to a (different) wrong code location when "stepping into" a function call.

   

If I look in the output window I see "The target program has stopped at: file: BLEM.c line: 345 function: test_sanity address: 0x00000304".  test_sanity() is the correct function that I called, but test_sanity() is not inside BLEM.c.

0 Likes
Anonymous
Not applicable

OK, so I've figured out a way to (seemingly) fix this, but it's very strange.  I took the offending file (BLEM.c in my case) and I removed it and its corresponding header BLEM.h from the project, then re-added it back in.  Rebuilt and now debugger works fine.

   

 Not sure if I ran into some weird bug in Visual Studio or something.  I'll update here if the problem reoccurs, or if I can find steps to reproduce it.

0 Likes
Anonymous
Not applicable

So the problem reoccurs every once in a while after modifying some code and rebuilding.  Each time I am able to fix it by removing the offending .c and .h file and rebuilding, then readding them back.  This will be ok for the time being but it's quite an ugly workaround.

Anonymous
Not applicable

In case anybody reads this, the problem seems to be related to breakpoints.  Leaving breakpoints from a previous debugging session seems to cause the problem.  Removing all breakpoints before building seems to cause it to work every time.

Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Thank you for sharing your experiences with us!

   

 

   

Bob

0 Likes
Bigby
Level 2
Level 2
25 sign-ins 10 sign-ins 5 replies posted

Hello,

I had a similar problem and in case anyone comes here in search for help, I would like to contribute my solution.

What helped for me, was to change the setting
Project → Build Settings → ARM GCC 5.4-2016-q2-up (or whatever toolchain you use) → Linker → Optimization → Remove Unused Sections
From True to False.

This highly increased flash usage but debugging works now.

0 Likes