CCS/TM4C1294NCPDT: Single step debugging does not work

C stepping through optimized code can be misleading. The C optimizer will often rearrange parts of a C code line to generate a more efficient code execution. This then makes it difficult for the debugger to interpret which assembly instruction goes with which line of C code. Often, one line of assembly code can be part of multiple lines of C code. When I run into a situation where C stepping does not make sense, I open the disassembly window and single step the assembly instructions. Then I see what the compiler did. (Which is usually what I told it to do instead of what I wanted it to do.) The other option is to disable optimization, or set optimization to level zero for the one file you are debugging. I do not often do this because it may hide my coding mistakes. For instance, I may not see that I failed to declare a variable volatile that needs to be.

Hi Bob,

thank you for the reply.

I as well thought of that but the optimization is off.

Here in this GUI it is off but when i look at the compiler option summary i did not found -O parameter so i changed it manually and now it says "-Ooff".

I don't think the optimization is the culprit because it is off. Or is the optimization still on although i explicitly set -O to off?

Best Regards

Akos

I am not seeing the problem. I see it C step into the switch statement but result is PARSE_NOT_COMPLETED. You have no case for that condition so it goes back to the while loop.

Hi Akos,

Akos Balassa said:

i only used "Single step over" and one time "step into".

Noted similar issue to CCS forum, IDE 9.2 ICDI debug simulator was not properly stepping over switch case for no match conditions. The next case fails to first block if the switch was no match or a break event occurred and the IP falls into each case regardless of the switch value. This is bad logic of ICDI simulator, Bob's work around I have not yet tried. 

Oddly I had set the case value very high by mistake but debug simulator still had bad logic on step over, step into. Others have posted about CCS switch case debug issues. 

Hi Bob,

single stepping through the switch statement you referring to in "displayData.c" (Line 94) works fine!

Debugging through the switch statement in "ieladLib.c" in the function "parserResult parser(unsigned char data, ieladMsg* displayMsg, ieladParserState* state)" on line 21 does not work.

Best regards,

Akos

I am not reproducing your results. You are running an RTOS. Do you have any other breakpoints set that might get hit in a task swap?

Hi Akos,

Are you certain double nesting switch case is even legal in C++, I've never seen that done.

Watching video x200 zoom noticed double nested switch statement inside the first switch statement, may require default break in there. A guru in CCS forum past stated C++ switch case is very basic and CSharp fixes some odd case behaviors. 

Hi Bob Hi Gl,

no there are no other breakpoints. In the video that i recorded the "Breakpoints windows" is visible for a brief time.

Gl said:

Are you certain double nesting switch case is even legal in C++, I've never seen that done.

I am not aware of any restrictions of how many switch cases can be nested. But i replaced the inner switch case with "if - elseif" statements and wasn't able to single step again. So it's not caused by the nested switch statement but with the switch statement itself somehow. Adding "default" does not help as well.

Regards,

Akos

Review of Switch Case from the book:

The switch statement causes control to be transferred to one of several statements depending on the value of an expression,which must have integral type. The sub statement controlled by a switch is typically compound. Any statement within the sub statement may be labeled with one or more case labels (§A9.l). The controlling expression undergoes integral promotion (§A6.1), and the case constants are converted to the promoted type. No two of the case constants associated with the same switch may have the same value after conversion. There may also be at most one default label associated with a switch. Switches may be nested; a case or default label is associated with the smallest switch that contains it. When the switch statement is executed, its expression is evaluated, including all side effects, and compared with each case constant. If one of the case constants is equal to the value of the expression, control passes to the statement of the matched case label. If no case constant matches the expression,and if there is a default label, control passes to the labeled statement. If no case matches, and if there is no default, then none of the sub statements of the switch is executed.

The continue statement is related to break, but less often used; it causes the next iteration of the enclosing for, while, or do loop to begin. In the while and do, this means that the test part is executed immediately; in the for, control passes to the increment step. The continue statement applies only to loops, not to switch. A continue inside a switch inside a loop causes the next loop iteration. As an example, this fragment processes only the non-negative elements in the array a; negative values are skipped.

for (i = 0; i < n; i++) {
if (a[i] < 0) /* skip negative elements */
continue;
/* do positive elements */
...
}

The continue statement is often used when the part of the loop that follows is complicated, so that reversing a test and indenting another level would nest the program too deeply.

The while loop portion may require continue?

While the above poster has (only) recently discovered "CMSIS" - he has reasonably quoted "K & R" - which he's (almost) properly identified as, "The" book.