#1005 Option "--xram-loc" ignored

closed
nobody
5
2005-11-14
2005-11-07
grasbon
No

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"

Discussion

  • Maarten Brock

    Maarten Brock - 2005-11-12

    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

     
  • grasbon

    grasbon - 2005-11-13

    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

     
  • Maarten Brock

    Maarten Brock - 2005-11-13

    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.

     
  • Nobody/Anonymous

    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

     
  • Maarten Brock

    Maarten Brock - 2005-11-14

    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

     
  • grasbon

    grasbon - 2005-11-14

    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

     
  • grasbon

    grasbon - 2005-11-14
    • status: open --> closed
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks