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.

Strange Bug in v6 CCS affect if - else statement



MCU/DSP F2808 (to be ported to F28335 soon). 

CCSv6  Version: 6.0.1.00040  most recent version (last week all downloaded and updated)

OPT=2 in complier setting

Issue: if statement can run code statement even false or true, very strange! ,has to use if else statement with __NOP to make it work correctly

Question: Why if statement run true statement code even condition is false (or true)?, what really happening,

Question : Is there fault in compiler optimization or setting

This is very fundamental bug, never seen anything like this before for 15 year programming (at mid level optimization).

R.  

----------------------------------------------------------------------------------------------------------------------------------------

 

       writedata= zTI_ComAdd.All.zWord & 0x0018;

 

       if (writedata == 0x0010)

       {

              UARTA_dsPIC33_Send_Status();

       }

       else

       {

              UARTA_dsPIC33_Protocol_Manager_Set_Status_NACK();      // Set NACK flag.

              UARTA_dsPIC33_Send_Status();

              return;

       }

The above code work, when writedata==0x0010 then it goes to true statement, otherwise false statement.

 

But….

 

Below code will not work correctly, in case of true or false condition it both executes false statement!!. I think this may be related to optimization.

 

       writedata= zTI_ComAdd.All.zWord & 0x0018;

 

       if (writedata == 0x0010)

       {

       }

       else

       {

              UARTA_dsPIC33_Protocol_Manager_Set_Status_NACK();      // Set NACK flag.

              UARTA_dsPIC33_Send_Status();

              return;

       }  

 

The fix is to add Nop statement in true statement

 

       if (writedata == 0x0010)

       {

              _NOP;

       }

       else

       {

              UARTA_dsPIC33_Protocol_Manager_Set_Status_NACK();      // Set NACK flag.

              UARTA_dsPIC33_Send_Status();

              return;

       }

---------------------------------------------------------------------------------------------------------

Especially

 

       if (writedata != 0x0010)

       {

              UARTA_dsPIC33_Protocol_Manager_Set_Status_NACK();      // Set NACK flag.

              UARTA_dsPIC33_Send_Status();

              return;

       }

Which will not work correctly, the NACK/Status statement executes under both true/false, the below is a correct fix.

 

       if (writedata != 0x0010)

       {

              UARTA_dsPIC33_Protocol_Manager_Set_Status_NACK();      // Set NACK flag.

              UARTA_dsPIC33_Send_Status();

              return;

       }

       else

       {

              _NOP;

       }


Take care!, compiler optimization can do strange thing using OPT=2 which is not that high level setting. 

       if ((zTI_ComAdd.All.zWord & 0x0018) != 0x0010)

       {

              UARTA_dsPIC33_Protocol_Manager_Set_Status_NACK();      // Set NACK flag.

              UARTA_dsPIC33_Send_Status();

              return;

       }

       else { _NOP;}                                          // Needed to fix bug, for proper operation.

 

Comment welcome…..

  • Richard,

    You may be experiencing the behavior described in the threads below. Please check the disassembly view in CCS to confirm if there is a MOVB instruction involved. If so, this is not really a bug but just the way it appears so when debugging in CCS. 

    http://e2e.ti.com/support/microcontrollers/c2000/f/171/p/190200/682158#682158

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

    Can you confirm that your code actually "executes" as expected (even though it may appear to be executing incorrectly in the debugger) and that the outcome of the program is not incorrect?

  • Thank Guru for quick reply....

    Can you advise how (or solution) to make sure if statement work correctly as I used <else {_NOP;} solution> so far. It make code bit messy.

    This not desirable bug, but open for ideas to resolve this.

    What can be done to resolves this in CCV6 release?

    I will try find time to check what stated in the link, using GPIO to confirm if debug affecting the process.
  • richard payne said:
    Can you advise how (or solution) to make sure if statement work correctly as I used <else {_NOP;} solution> so far. It make code bit messy.

    You can single step through the code while looking at the assembly instructions and see whether the code executes as expected or not (for example, whether the instruction within the if-else actually completes or not). Some understanding of the assembly instructions and what they do would definitely be helpful for this analysis.

    richard payne said:
    What can be done to resolves this in CCV6 release?

    If this is indeed the issue you are seeing, then as I said earlier it is not a bug. Also a general note about debugging: debugging ability decreases as the optimization level increases. This is because with higher levels of optimization code is moved around, variables are optimized and so on, all of which affect debugging capability. In such cases, trying a lower level of optimization or disabling optimization altogether will improve the debug experience.