We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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...
please show the C
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...