This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Error in assembled output? return value loaded after RET

After compiling, a section from my src file looks something like this:

;
; U08  ReadOtpU08( const OTPAddr addr )

        RSEG  ?PR?_ReadOtpU08?OTPCOMMIT
_ReadOtpU08:
        USING   0
                        ; SOURCE LINE # 157
        MOV     addr?549,R6
        MOV     addr?549+01H,R7
; {   // Must be within OTP Range {{{
                        ; SOURCE LINE # 158
;     ASSERT( addr < OTP_SIZE );
; //P0 = 0xAA;
;     TRACE((" - %bx - ", otpCodeRead.codeSpace[addr] ));
                        ; SOURCE LINE # 161
        MOV     R3,#0FFH
        MOV     R2,#HIGH (?SC_30)
        MOV     R1,#LOW (?SC_30)
        LCALL   L?0045
        MOV     ?_printf?BYTE+03H,A
        LCALL   _printf
;     return otpCodeRead.codeSpace[addr];
                        ; SOURCE LINE # 162
        CLR     A
        ADD     A,addr?549+01H
        MOV     DPL,A
        MOV     A,#080H
        ADDC    A,addr?549
        MOV     DPH,A
        CLR     A
        MOVC    A,@A+DPTR
        MOV     R7,A
;     // }}}
; }
                        ; SOURCE LINE # 164
?C0017:
        RET
; END OF _ReadOtpU08

;

but the assembled output produces:

....
C:0x8A99    E4       CLR      A
C:0x8A9A    2569     ADD      A,0x69
C:0x8A9C    F582     MOV      DPL(0x82),A
C:0x8A9E    7480     MOV      A,#P0(0x80)
C:0x8AA0    3568     ADDC     A,0x68
C:0x8AA2    F583     MOV      DPH(0x83),A
C:0x8AA4    E4       CLR      A
C:0x8AA5    93       MOVC     A,@A+DPTR
C:0x8AA6    22       RET
C:0x8AA7    FF       MOV      R7,A

which clearly shows the result being moved to R7 after the return ??!!

Can anybody shed light on this: Apologies if I'm overlooking the obvious...

  • Not much to see really, The list src file has the most of it. I'm trying to create a better (smaller) test case, but the issue is very sensetive to changes. Its also worth mentioning that the recieving code promptly moves R7 into the accumulator, thus undoing all the good work.

    
    /**
     * @class OTPCode
     * Structure that represents the otp code layout
     */
    typedef struct
    {
        U08     codeSpace[ 0x7bfd ];
        U16     checksumConfig;
        U16     checksumSignature;
    } OTPCode;
    
    
    #define CODE_STRUCTURE(struc, base)   (*((struc const code*)(base)))
    
    #define otpCodeRead  CODE_STRUCTURE( OTPCode, BASE_OTP )
    
    
    /**
     * ReadOtpUnn reads a Unn from the OTP memory
     * @param addr is const OTPAddr and is a 15-bit U32 aligned address to which we wish
     * to read.
     * @return Unn and is the dat to be read from this address.
     */
    U08  ReadOtpU08( const OTPAddr addr )
    {   // Must be within OTP Range {{{
        // ASSERT( addr < OTP_SIZE );
        printf(" - %bx - ", otpCodeRead.codeSpace[addr] );
        return otpCodeRead.codeSpace[addr];
        // }}}
    }
    
    

  • Update: The disassembly I listed turns out to be a common subexpression that returns data in the accumulator. In fact the correct machine code was nearby, and almost identical ( but ending in FF 22 ).

    There was a real issue with the values returned from my code, but it looks like it is an issue with our 8051 implementation performing concurrent accesses on the code bus rather then Keil tool.

    So issue resolved: Sorry for wasting anyones time,

    PS - If anyone knows how to get a text file of mixed assembly and C with absolute addresses post linking, similar to the one seen in the simulator, I would be intrested in knowing?

  • "If anyone knows how to get a text file of mixed assembly and C with absolute addresses post linking"

    That would be the Linker's .cod file.

    It requires the LX51 Linker, and possibly a few other option settings - I forget...