TMS320F28379D: Apparent bug in firmware if/else execution using asm breakpoint labels from a DSS script

The compiler has done nothing wrong.  The problem is in your presumption that there is exactly one way to reach an asm created label that appears at the end of a block controlled by an if/else condition.  As you will see, that presumption is incorrect.

Thank you for submitting a CCS project.  I built it with C2000 compiler version 20.2.5.LTS.  In particular, I made sure to use compiler option --opt_level=1. I also added the option --src_interlist.  This causes the compiler to not delete the auto-generated assembly file, and to add comments to it which make it easier to understand.  The assembly file has the same name as the source file, with the file extension changed to .asm.  Consider the file GpioInputCheck.asm.  To make it easy to focus on the lines that matter, I changed the file in these ways:

• Only the function CheckIdInputs remains
• All the directives, like .text and .dwattr, are removed
• All blank lines are removed

Here it is:

_CheckIdInputs:
;* AR4   assigned to $O$C1
;* AL    assigned to _bGpioInputsAreValid
;*** 81	-----------------------    if ( !*(C$1 = &GpioValues[0]) ) goto g4;
        MOVL      XAR4,#_GpioValues     ; [CPU_ARAU] |81| 
        MOV       AL,*+XAR4[0]          ; [CPU_ALU] |81| 
        B         $C$L3,EQ              ; [CPU_ALU] |81| 
        ; branchcc occurs ; [] |81| 
;*** 81	-----------------------    if ( !C$1[1] ) goto g7;
        MOV       AL,*+XAR4[1]          ; [CPU_ALU] |81| 
        B         $C$L5,EQ              ; [CPU_ALU] |81| 
        ; branchcc occurs ; [] |81| 
;*** 86	-----------------------    if ( GpioValues[0] ) goto g6;
        MOVW      DP,#_GpioValues       ; [CPU_ARAU] 
        MOV       AL,@$BLOCKED(_GpioValues) ; [CPU_ALU] |86| 
        B         $C$L4,NEQ             ; [CPU_ALU] |86| 
        ; branchcc occurs ; [] |86| 
$C$L3:    
;***	-----------------------g4:
;*** 86	-----------------------    if ( !GpioValues[1] ) goto g6;
        MOVW      DP,#_GpioValues+1     ; [CPU_ARAU] 
        MOV       AL,@$BLOCKED(_GpioValues)+1 ; [CPU_ALU] |86| 
        B         $C$L4,EQ              ; [CPU_ALU] |86| 
        ; branchcc occurs ; [] |86| 
;*** 88	-----------------------    _bGpioInputsAreValid = 1u;
;*** 89	-----------------------    asm("VALID_CASE_1:");
;***  	-----------------------    goto g8;
        MOVB      AL,#1                 ; [CPU_ALU] |88| 
VALID_CASE_1:
        B         $C$L6,UNC             ; [CPU_ALU] 
        ; branch occurs ; [] 
$C$L4:    
;***	-----------------------g6:
;*** 93	-----------------------    _bGpioInputsAreValid = 0u;
;*** 94	-----------------------    asm("INVALID_GPIO_INPUTS:");
;*** 94	-----------------------    goto g8;
        MOVB      AL,#0                 ; [CPU_ALU] |93| 
INVALID_GPIO_INPUTS:
        B         $C$L6,UNC             ; [CPU_ALU] |94| 
        ; branch occurs ; [] |94| 
$C$L5:    
;***	-----------------------g7:
;*** 83	-----------------------    _bGpioInputsAreValid = 1u;
;*** 84	-----------------------    asm("VALID_CASE_0:");
;***	-----------------------g8:
;*** 97	-----------------------    return _bGpioInputsAreValid;
        MOVB      AL,#1                 ; [CPU_ALU] |83| 
VALID_CASE_0:
$C$L6:    
        SPM       #0                    ; [CPU_ALU] 
        LRETR     ; [CPU_ALU] 

This code is correct, in the sense that it returns the correct result for all input.  But notice lines 48 and 49.  They each define a label, for the same address.  Line 48 defines the label VALID_CASE_0 and line 49 defines the label $C$L6.  Any label that begins $C$ is a label generated by the compiler.  Note that there are two branches to $C$L6.  One on line 30, and another on line 39.  Suppose execution reaches line 30.  That means the breakpoint for VALID_CASE_1 is seen.  What happens next?  An unconditional branch to $C$L6.  That means the breakpoint for VALID_CASE_0 is seen, even though the instruction just before it does not execute.  It is a similar situation when execution reaches line 39. 

I'm unsure of the best solution.  One quick workaround is to add a nop to each asm statement.

    asm("VALID_CASE_0: nop");

Thanks and regards,

-George