#1005 Option "--xram-loc" ignored
Version:
SDCC :
mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08
2.5.4 #1148 (Nov 6 2005) (MINGW32)
OS: Win
The compiler ignores the option "--xram-loc", when
xdata-variables are initialized outside the code like this:
"Main.c":
xdata unsigned char v = 'x'; // Will be placed at 0x0000!
void main(void)
{
v = 'u'; // Ok, Places at 0x0100!
}
Compiler-call: "sdcc --xram-loc 0x0100 Main.c"
The option for the compiler let start the xdata-area
at 0x0100. The value 'x' of the variable 'v' will be placed
at wrong destination (0x0000). The second assignment,
inside main() places the value at the correct address,
at 0x0100. So, maybe there's a problem within the startup-
code.
Nice Greetings
Reimar Grasbon.
Questions? Here I am: "mail@grasbon.de"
Logged In: YES
user_id=888171
Reimar,
Which derivative are you using? One with internal xram? If
so, chances are that you must tell SDCC which sfr is used
for page addressing in xram. You must define sfr _XPAGE for
that. Another possibility is that you must enable the internal
xram before you can use it. That should happen in
_sdcc_external_startup(). The last option is that you cannot
use movx @Rn instructions to access outside the first 256
bytes of xram on the derivative at all. This would require a
changed version of crtxinit.asm, maybe using dual data
pointers.
Maarten
Logged In: YES
user_id=1374486
Hi Maarten,
it's no special derivate. I use a standard 8031 without
internal xram. Also I do not use pdata (movx @Rn). So,
there's no sfr or something else to initialize before using
xdata.
Greetings,
Reimar
Logged In: YES
user_id=888171
movx @Rn instructions are used during xdata initialization in
crtxinit.asm.
If you use a standard 8031 I see no reason why this would
fail. I cannot reproduce the bug.
Logged In: NO
"movx @Rn instructions are used ..."
Exactly that's the problem. Initialization of upper external
memory (above 0x100) with "movx @Rn" instructions isn't
possible.
Obviously the problem is inside "crtxinit.asm" but I can not
prove it because I didn't download the sources so far. So,
have a look at the assembly from "main.ihx" starting at
address 0x0022:
[...]
0022 93 movc A, @A+DPTR ; Load 'x'
0023 A3 movx @R0, A ; Place 'x' in @R0 (= 0)
[...]
Hence, the 'x' will be placed at xdata-address 0 (= pdata
address 0) by what the "--xram-loc"-option will be ignored.
Later in the code we will find the the 'u'-assignment:
[...]
0064 90 01 00 movc DPTR, #0100 ; address: 0x100
0067 74 75 mov A, #75 ; Load 'u'
0069 F0 movx @DPTR, A ; Place 'u' in 0x100
[...]
The value 'u' will be written to 0x0100. That's correct.
Did I overlook something in the documentation?
Regards,
Reimar
Logged In: YES
user_id=888171
Reimar,
You don't have to download all sources to view crtxinit.asm.
Click CVS on the SourceForge site and browse to
sdcc/device/lib/mcs51/crtxinit.asm
As you can see movx @r0,a is preceeded by
mov __XPAGE,#(s_XISEG >> 8)
and __XPAGE is incremented outside the inner loop.
"--xram-loc 0x100" sets s_XISEG to 0x100. __XPAGE in asm
equals _XPAGE in C and defaults to P2 if not explicitly
defined. This should be sufficient on an 8031.
Maarten
Logged In: YES
user_id=1374486
Yep, you're right,
my simulator ignored the P2-hi-byte in combination with
"pages moves". So I did not realize, that the XPAGE setting
for my cypress chip was wrong.
I will close this entry now.
Reimar