CODECOMPOSER: IF statement entered without condition being met to enter it

Hi Dale,

What TI device is this running on?

A cc2640f128 with a progam that has been running for years and I just added that small bit of code

This is not definitive, but this code below works to get me a breakpoint that actually breaks when the condition is met:

The function breakpoint() simple returns tdif+1 so the 6 added lines do not change the value of tdif.

Only one tdif=breakpoint()-1; line did not work  to get a REAL breakpoint, so I tried 6 of them and it worked, I have no more time to isolate this solution.

EDIT: I just found another way to have the code break properly there.

I put a 'write' 'hardware watchpoint' on the variable 'expectingbackfromnextion'.

I can shed some light on what probably happened.  Consider this contrived example ...

int fxn(int arg)
{
   if (arg)
   {
      return 10;
   }
   else
   {
      return 20;
   }
}

I use the TI ARM compiler to build it.  But, for the purposes of this example, that detail doesn't matter much.  Other compilers can generate similar code.  Here is the assembly code generated in this case ...

fxn:
;* --------------------------------------------------------------------------*
        CMP       A1, #0                ; [DPU_V7M3_PIPE] |5|
        ITE       NE                    ; [DPU_V7M3_PIPE]
        MOVNE     A1, #10               ; [DPU_V7M3_PIPE] |5|
        MOVEQ     A1, #20               ; [DPU_V7M3_PIPE] |5|
        BX        LR                    ; [DPU_V7M3_PIPE]

Because of how the IT instruction is used, there are no conditional branches in this code.  All of those instructions execute.  Based on the value of arg that is passed in, one of the MOV instructions has no effect.  Suppose you set a breakpoint on one of the return statements.  You'll hit it.  But the condition related to that return may not be active at that particular moment.

This is an example of how optimization can cause debugging to be difficult.  For more on this issue, please see the article Debug versus Optimization Tradeoff.

Dale Kramer said:

Does anyone know of a line of code that can be placed anywhere in my code that will GUARANTEE a breakpoint can be set on that line AND that if the breakpoint triggers on that line, code execution is REALLY there

A guarantee?  No.  But I can make a suggestion that will work often enough it is worth trying.  Add asm statements that execute a nop ...

int fxn(int arg)
{
   if (arg)
   {
      asm(" nop");
      return 10;
   }
   else
   {
      asm(" nop");
      return 20;
   }
}

Generally speaking, asm statements are to be avoided.  I presume you will use them only on a temporary basis, as a way to aid debugging.  In that case, I suppose asm statements are OK.  The generated code performs the branches you expect.  You can set breakpoints on the asm statements.  That's how it will work out a lot of the time.  But no one can guarantee it always works.

Dale Kramer said:

I put a 'write' 'hardware watchpoint' on the variable 'expectingbackfromnextion'.

I think that is a better solution than using asm statements.  That said, it is good to know about multiple methods.

Thanks and regards,

-George