• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 52 subscribers
  • Views 513 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Delfino CCS3.3 breakpoint / editor text sync issue, breaking on both if and else paths of "if" ???

C Wida
Prodigy 20 points
We are working with the Delfino C28346 and we have been noticing some weird debug issues with CCS 3.3 and the part. We have all the newest updates installed but when we set break points it doesn’t always stop where the break point is set. Sometimes it stops before or after or even in logic conditions that shouldn’t be triggered. All the optimization is off and full symbolic debug is on. Have you guys ever experienced this and do you know a possible solution?
CCS 3.3, IDE 5.98.0.393, Code Gen Tools v5.2.3, DSP/BIOS 5.31.02, emulator Spectrum DIgital XDS510 USB Plus
Test Case :
int i = 0;
if (i < 0) {        <- put breakpoint here
run = true       <- put breakpoint here
}
else  {
run = false          <- put breakpoint here
 }
Code execution will stop on all three lines. Sometimes execution never stops at a breakpoint but by checking watch window at a different location, we know that the path had indeed been executed even though the breakpoint was never hit.
  • 0
    TI__Guru* 92140 points

    The C28x has some conditional assembly move instructions.  My guess is if you take a peek at the assembly code you may see these instructions. 

    For example:

    MOVL loc32, ACC, GT   

    This instruction will save off the contents of ACC only if the status flags indicate "greater than".   If the condition is not true it behaves as a NOP - meaning it doesn't do anything but is still executed.

    Here is a similar thread with an example:

    http://e2e.ti.com/support/development_tools/f/81/p/3431/12180.aspx#12180

    -Lori

  • 0 in reply to Lori Heustess
    Prodigy 20 points

    Thanks Lori. That does help with some of it. However, if I have an if statement with no else and set a variable inside the if, then set a break point, the breakpoint is never hit. If I put a breakpoint on the last line in a routine before it returns, I check the variable inside the if and the value shows that the path was taken, but execution never stopped on the breakpoint.

    Like this:

    if (i<0) {

    flag = true    <- set breakpoint here

    }

    blah

    blah

    blah

    return;     <- set breakpoint here

    Result is that the first breakpoint is never hit AND the variable flag has been changed to true.

     

     

     

     

     

     

  • 0 in reply to C Wida
    TI__Guru* 92140 points

    Is it like this?

    main ()

    {

       int i = -10;

       if (i<0) {

       flag = true    <- set breakpoint here

       }

    etc..

    if so it is possible the compiler has optimized out the if - it basically says "hey I know what i is already - it is -10, I don't need to check it".  

    I would need to look at the generated assembly code to confirm if this is the case.  Can you paste the disassembly window contents?

    If you make i volatile then it will force the check, but that can lead to inefficient code when if it is not needed.  Volatile should only be used for registers or variables that can change outside of the current context.

    -Lori