CCS4 Breakpoints breaking when shouldn't

Which version of CCS are you using? And what are the project compile options? The options should be displayed in the console view when building your project.

Is optimization enabled in the build options, if so what level? (Check under Project->Build Properties->Compiler->Basic Options->Optimization level). This might be a side-effect of debugging with optimization. Many times when optimization is turned on, the source line correlation is affected, thereby making the debug experience more difficult. Try lowering the optimization level or disabling it completely and see if the behavior changes. You could also debug the issue further by opening the CCS Disassembly view in mixed mode to get a better understanding of the assembly code generated by the compiler for this routine, and see where the breakpoint is actually being set/hit.

Thanks Aarti,
The version of CCS is: Version: 4.1.0.02000
The Project Menu doesn't have "Build Properties".  I think I found it under "Project>Properties>C/C++Build>ToolSettingsTab>BasicOptions (under TMS470 compiler) and the Optimization level is set to '2'. Note: that teh Properties item in the menu is greyed out unless you select: "C/C++ Perspective" and you then select the projectin the C/C++ Projects windo. This took me a while to figure out and was not at all obvious. 
Target processor version is 7M3 (whatever that means), Enable 16bit code is not checked, Debugging model is set to Full symbolic debug and Optimize for speed has nothing selected.

What should I set it to?  I'll try 1 or 0 and see if that works.  (i'm not at my station with the hardware at the moment, so I'll update the post in a couple days when I can get to it).
Is there a way to mark some lines of code to get optimized at a different level (so I can include debugging statements and have them not optimized out, etc.)?

Also, I was trying to get the thing to build in a release configuration, but I got a bunch of errors that didn't make sense to my newbe mind.  How do I go about trying a release configuration?

By the way I set this all up from an example design using a freeRTOS port for CCS4 which used a differnent processor (lm3s8962 and I'm using the lm3s6965). 
Maybe I missed somethings when I changed the settings for my processor.

Tim.

Tim King said:

What should I set it to?  I'll try 1 or 0 and see if that works.  (i'm not at my station with the hardware at the moment, so I'll update the post in a couple days when I can get to it).

You could start with no optimization (leave the field blank) and then work up to level 0 or 1.

Tim King said:

Is there a way to mark some lines of code to get optimized at a different level (so I can include debugging statements and have them not optimized out, etc.)?

 Newer versions of the compiler allow controlling optimization levels on a per function basis, but for that you would need to update your compiler tools. For now, with the version included in CCS, you can control it at a file level. To do so, right-click on the C source file in the C/C++ Projects view, go to Properties->C/C++ Build and set the file specific options as needed.

Tim King said:

Also, I was trying to get the thing to build in a release configuration, but I got a bunch of errors that didn't make sense to my newbe mind.  How do I go about trying a release configuration?

When creating a new project, by default, a Debug and Release configuraiton is created. The build options typically differ between these 2 builds, with Debug configuration usually having no or low optimization (to emphasize more debuggable code), and Release configuration usually has higher levels of optimization. I believe the Stellarisware examples use the same build options for Debug and Release though. To check for sure, just compare the build options for the 2 configurations by first setting the Active Build Configuration to either Debug or Release, and then going to Project->Properties->C/C++ Build, highlighting TMS470 Compiler and look at All Options.

I tried it with the optimization set to '0':  It still stops inside the 'if' statement when the 'if' is false (when it shouldn't).

I tried it with the optimization left blank:  Now I can't put the break point within the 'if' statements. The break points just jump to the next statement outside the 'if' block.

What should I do now?

Thanks,

Tim.

Now it is totally hosed!

I tried to "debug active project" and I get:

Error connecting to the target:
LMI device check failed, bad part number detected.

What's wrong now?  It was working at least without the  breakpoints. Now I can't even get it to load the code to the board.

Help!

Tim.

Update:  I got the board working again using LM Flash Programmer>Other Utilities>Debug Port Unlock (Fury & DustDevel Classes).
I'd stil like to know how  to make the break points land where i want.  Also, I'm not sure how changing the optimization screws up the debug connection to the board.

?

With respect to the breakpoint issue:

Disclaimer: I am not sure if this occurs on the Stellaris but it does occur in the C2000 I use. So this may help or it may not.

Have a look at the assembly for the section you are decoding.  From my first instincts the C compiler would compile it like this:

Compare

BP> Conditional Branch to end

Compare

Conditional Branch to end

End:

Now if you put a BP on the Conditional Branch (break) it will occur all the time as the conditional branch instruction is executed 100% of the time, but what it does is different.  The way around this is to add some instructions such as NOPs to the inside of the conditional statement,

e.g.

NOP (however you do it in Stellaris)

break; (optional in an IF statement)

This will most likely compile to:

Compare

Conditional Branch to end

NOP

bp> Unconditional Branch to end

Now your breakpoint will only occur if the condition is true.

 

Hopefully this helps,

 

Tim

Hi Tim,
Thanks for the info.  That is probably what is going on.  I haven't delved into the assembly instructions for this processor yet so I didn't look for that in the dissassembled code in the debugger. 

I'll have to check that out next time I'm debbugging it. 

Is there a good way to put a 'NOP' in C for the stellaris out there--anyone?
I wonder if just toggling an volatile global variable would do it.

Thanks again,

Tim.

Hi,

I am having the exact same problem using the C2000 compiler for the F28335 controller. I use code composer studio Version: 5.1.0.09000 on Windows 7 64bit and have tried the suggestions for different settings in this discussion. When placing the breakpoint within a conditional "if" statement, the debugger breaks inside the if statement, although the code inside the if statement is (correctly so) not executed.

It is a bit frustrating to do rappid development with paid and licenced tools that need to be debugged itself. I have applied all the latest updates but still find that this problem persists. Does TI have a permanent solution, fix or patch for this problem? Are any work being done to solve this? Here is an example of the code:

001:toets = 0;
002:status = 2;
003:if(status == 0)
004:{
005:           toets = 4;
006:           DataLink_Ontvang_Proses_Toestand = 2;                    // <-- BREAKPOINT IS PLACED AND BREAKS HERE.
007:}

A breakpoint is placed at line 006. From this code snippet, line 005 and 006 can never execute. But, the debugger breaks at line 006 although the value of variable 'toets' still remains 0; Am I missing something?

Thanks!

DMT Tomlinson said:

When placing the breakpoint within a conditional "if" statement, the debugger breaks inside the if statement, although the code inside the if statement is (correctly so) not executed.

The behavior you are seeing is the same as what was explained by Tim King61612. Take a look at the assembly code generated by the compiler (in the CCS disassembly window). There should be a CMP instruction which sets flags based on the result of the comparison.  Then a MOVB within the if is conditional and will only occur if the flags indicate the condition is true. The debugger will halt at the instruction because the instruction is always executed - it is just the outcome that depends on the condition. It may be confusing from a debugging point of view but in terms of code it is much more efficient than a branch.

Please take a look at the related threads which also explain the behavior:

http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/3431/12180.aspx#12180
http://e2e.ti.com/support/development_tools/compiler/f/343/p/69946/253629.aspx#253629