Why are breakpoints not working, and how do I fix it?

[NNeff]

I'm running CodeWarrior for MCUs 10.6 build 140329, special edition.  Target is a KE06Z, debugging over the OpenSDA interface.  I'm creating a .elf file with debug info,  The debugger is ignoring any breakpoints I set.  It comes up with the message that some breakpoints may not work, but none of the ones set work, even at places not optimized away or otherwise places that should work.  What could be causing this, and how do I fix it?

One thing I've wondered about, and can't figure out how to tell, is whether I've gone over the code size limit for the special edition version of CodeWarrior.  How does one know?  My source code files total about 142 KB in Windows, but that's with the byte size rounded up because of disk sectors, and all the comments in the code, so the actual source size is considerably less than that, but it looks like I might be pushing the limit.  How does one know when you've gone over the limit as far as CodeWarrior is concerned?  Could this be related to breakpoints not working?

[BlackNight]

Hi Nancy,

You can get the code size with the map file produced by the linker, or better with the 'print_size' utility:

GNU Additional Tools: Create Flash Image, Print Size and Extended Listing Options ​

or

Code Size Information with gcc for ARM/Kinetis

This article helps to understand the information:

text, data and bss: Code and Data Size Explained

About the breakpoints problem: You only can set a limited number of (hardware) breakpoints, depending on the device you are using (see as well Software and Hardware Breakpoints). I recommend that you have a look at the 'Breakpoints' view to check how many you have set. You can deal with this with 'skipping' breakpoints (see Skipping Breakpoints​). Another way is to use a Segger J-Link (or OpenSDA Freedom firmware) which has 'unlimited flash breakpoints' (see Freedom Board with Segger OpenSDA Debug Firmware).

Or could it be that you have 'skip all breakpoints' enabled?

I hope this helps,

Erich

[NNeff]

Thank you Erich for the links to the blogs on code size. I'm at 41 KB, so that's not the cause of CodeWarrior's strange behaviors.

I didn't have "skip all breakpoints" selected--I wish it were so easy. I have some breakpoints working--the ones I thought should be working were on code that has been optimized so that the function call won't work as a breakpoint.  (I hesitate to say that the function has been in-lined because it's far too big for that, and anyway, the debugger could still stop on the first line, but the failure of some of the breakpoints seems to be related to optimization.  I have to look at the disassembly further.)

Now, however, I'm seeing a new problem:  when I click on "stepping over", the debugger is instead going into the function I'm trying to step over.  It wasn't doing this yesterday, and I haven't changed the settings except to produce the .lst file using the Additional Tools as discussed in one of the blogs on code size.  When I selected "run to line" on the return at the bottom of the module I had tried to step over, the executable started free-running rather than stopping at the selected line.

I haven't had these sorts of problems on the previous programs I've developed for a Kinetis board using CodeWarrior for MCUs.  It's frustrating and a little puzzling.  I'm going to turn off optimizations and see if the debugger behaves more predictably.

Thank you again for the pointers. (C pun :-)

[NNeff]

Oh.  Optimization level was already set to "none", so what appears to me to be unpredictable behavior by CodeWarrior is not due to code optimization.  Hmm.

[BlackNight]

Hi Nancy,

the behaviour you describe matches my experience if running out of hardware breakpoints. Are you sure you have not say more than 3 breakpoints set, and all others disabled?

Erich

[NNeff]

The only way I know how to tell how many are set is to look at the list of breakpoints on the "Breakpoints" tab.  If breakpoints can be set but not listed there, then that seems to me to be another problem with CodeWarrior!  Right now I have 3 set (I'm on a KE06Z, which I thought allowed me up to four--?), and the Step Over button is not functioning correctly:  CodeWarrior is stepping INTO the function instead.  Trying to step and return (the arrow coming up on the button) results in an error "Target request failed: Failed to step, An error occurred while trying to set a software breakpoint.", so I guess three breakpoints are too many. ... I just reduced the number of breakpoints listed on the Breakpoints tab to one, and both stepping over and the step-return are working. If I set two breakpoints, the step-over starts stepping into the function instead.  One seems like a very small number of breakpoints to be a reasonable number, but I guess you are right, that this behavior is due to too many breakpoints being set.  This is very limiting, and something I don't remember from a couple of previous programs using the KE06Z.  Could there be a problem with an individual board that would cause the number of breakpoints to be reduced?

[BlackNight]

Hi Nancy,

this looks like a bug in CodeWarrior to me: indeed, for KE06 it is only able to set two HW breakpoints:

I have used KE06 in Kinetis Design Studio, and here it works properly: I can set up to 4 HW breakpoints (3 if I want to do step-over, as step-over needs one extra breakpoint). As a workaround you could use Skipping Breakpoints.

Or you could use the Segger OpenSDA/J-Link firmware (see Freedom Board with Segger OpenSDA Debug Firmware).

Or use Kinetis Design Studio if that's an option.

I'll file a ticket about that CW breakpoint problem.

I hope this helps,

Erich

[BlackNight]

Hi Nancy,

I'm sorry, I have to take that back: indeed, the KE06 has only two hardware breakpoints implemented. So if you set more than one, then stepping is affected.

I have been confused by the fact that GDB seems to behave incorrectly if running out of hardware breakpoint: there you will step-over, but not step-into (different from CodeWarrior). Bottom line is that the hardware has not more breakpoints, so you would have to use 'skipping breakpoints' or use the Segger J-Link instead.

Sorry again,

Erich

[NNeff]

KE02 or KE06?  I'm using the KE06, and I'd swear that I could set more than one, or two, breakpoints in my previous projects--same debug interface, same version of CW.  I think I will see how difficult it would be for our hardware guy to change out the board in case there's a fault with this processor. Does that make sense?

[BlackNight · Accepted solution]

It is KE06 I have used (I mistyped the number). I used the FRDM-KE06, and it only allowed me to set two breakpoints (see screenshot I have posted).

[NNeff]

Bummer!  Thanks for taking so much time with this question--I appreciate it.  --Nancy