The MCU I used is SM8958A,which has 1K bytes on-chip RAM, 256 bytes of it are the same as general 8052 internal memory structure while the expanded 768 bytes on-chip RAM can be accessed by external memory addressing method (by instruction MOVX).The SCONF and RCON should be setting when the expanded 768 bytes on-chip RAM is used.The meaning of RCON is below:
SM8958A has 768 byte on-chip RAM which can be accessed by external memory addressing method only. (By instruction MOVX). The address space of instruction MOVX @Rn is determined by bit 1 and bit 0 (RAMS1, RAMS0) of RCON. The default setting of RAMS1, RAMS0 bits is 00 (page0).
RAMS1 RAMS0 MOVX @Ri i=0,1 mapping to expended RAM address 0 0 $0000 ~ $00FF 0 1 $0100 ~ $01FF 1 0 $0200 ~ $02FF
Now I write the code below:
unsigned long pdata a; unsigned long xdata b; SCONF |= 0x02; //enable the 768 Ram RCON |= 0x01; //$0100 ~ $01FF
When I press F5, I find the position of 'a' in the memory is X:0x0001A4,and the auto disassemble instruction is mov r0, #0xA4, however,the position of 'b' in the memory is X:0x0002BF,and the auto disassemble instruction is movx DPTR,#02BF.
Finally, the program where used 'a' runs wrong,but the program where used 'b' runs right.
But when I program the HEX file into the MCU, let it run in the hardware , the program runs ok.
So, I'm very puzzled: Keil's Debug is right or wrong?
Note This message was edited to reduce width.
and the auto disassemble instruction is mov r0, #0xA4
There's nothing wrong with that. So the problem must be elsewhere.
Are you sure that you configured all parts of Keil correctly for using PDATA in page 0x01? And why use page 01 anyway? It's in the middle of your XRAM, so you're fragmenting your XDATA space for no apparent reason.
Thank you for answering my question, can you tell me how to config correctly while using PDATA in page 0x01? There is what I did:
Device: AT89S52 #include <AT89X52.h> Memory Model: Small
I just define 'a', and do nothing else. The address of 'a' in memory is auto assigned by the simulator,I guess.
I am puzzled that while the address of 'a' in memory is X:0x0001A4, the disassemble instruction is mov R0,#0xA4, not mov DPTR,#0x01A4
mov R0,#0xA4 just move the value from X:0x0000A4 , not X:0x0001A4， that is what I am puzzled. You know, the address of 'a' in memory is X:0x0001A4 at that time. I'm sorry I did not describe my problem clearly.
mov R0,#0xA4 just move the value from X:0x0000A4 NO, it does not! it moves 0xa4 into r0 I huess the next instructions will be mov a,@R0 THAT will move what is at xxa4 in memory into the accumulator. xx will be either the contents of P2 (traditional approach) or if your derivative - which I never have heard of - has a "high memory address SFR" by whatever name, it will be the contents of that.
Erik
mov R0,#0xA4 just move the value from X:0x0000A4 NO, it does not! it moves 0xa4 into r0 I huess the next instructions will be movX a,@R0 THAT will move what is at xxa4 in memory into the accumulator. xx will be either the contents of P2 (traditional approach) or if your derivative - which I never have heard of - has a "high memory address SFR" by whatever name, it will be the contents of that.
What part of "there's absolutely nothing wrong with that" didn't you get the first time? If PDATA behaved exactly like XDATA to work, why would they exist as separate memory classes in the first place?
Frankly, you need to spend a lot more time on studying the 8051 architecture (memory architecture, opcodes, addressing modes, and all that) before going ahead reading disassembled code and drawing conclusions from what you think you see.
Thank you for helping me. Now I understand more than before. I config Pdata in the Startup.A51 file.
In simulation, P2 is the uppermost address of pdata variable, but in real mcu, P2 is no effect . So I guess keil's simulation have some flaw.