• State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 22 subscribers
  • Views 2887 views
  • Users 0 members are here
Options
Related
How was your experience today?
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

C166: Call-segmented to a ram-address does not work

Josef Aspelmayr

Hello,

I use a ST10F269 (SMALL-modell) with Keil C166 v6.
I try to call a RAM-routine (in XRAM2) from ROM (in Segment 2 => all code is located within 64kB in Segment 2) via assembler routine:

BCLR IEN
CALLS #0,#SOF fls_ram
BSET IEN

fls_ram is a variable at address 0xDBBE

What I expect is, that the call is to address 0xDBBE but it is to address 0x9BBE (14bit address).

When I use:
MOV R4, #SOF fls_ram
it works fine, I have the 16bit-address in register R4 but not with CALLS, JMPS, ..

Are there restrictions for the use of #SOF?
How can I jump to the RAM-area (in a different segment)?

Thanks for the help!

Best Regards,
Josef Aspelmayr

Parents
  • 0 in reply to Chris Wunderlich

    Hello Chris,

    thanks for the help!

    I have tried your code-snippet, but with variable located in XRAM-area:

    00C200H     fls_ram  VAR   ---  NDATA0  ?ND0?TEST

    And it works!

    But I have tried to do the same with #pragma ASM and I get the same failure:

    unsigned int fls_ram[50];

void MyFunc(void);

void main(void) {

  fls_ram[0] = 0x00DB;  /* RETS instruction */
  MyFunc();

  for(;;);
}

void MyFunc(void)
{

#pragma ASM
  CALLS   #0, #SOF fls_ram
#pragma ENDASM
}

    In that case I have a:

    CALLS 0x8200


    .. so this is wrong!

    Best Regards,
    Josef

Reply
  • 0 in reply to Chris Wunderlich

    Hello Chris,

    thanks for the help!

    I have tried your code-snippet, but with variable located in XRAM-area:

    00C200H     fls_ram  VAR   ---  NDATA0  ?ND0?TEST

    And it works!

    But I have tried to do the same with #pragma ASM and I get the same failure:

    unsigned int fls_ram[50];

void MyFunc(void);

void main(void) {

  fls_ram[0] = 0x00DB;  /* RETS instruction */
  MyFunc();

  for(;;);
}

void MyFunc(void)
{

#pragma ASM
  CALLS   #0, #SOF fls_ram
#pragma ENDASM
}

    In that case I have a:

    CALLS 0x8200


    .. so this is wrong!

    Best Regards,
    Josef

Children
  • 0 in reply to Josef Aspelmayr

    I left off the reference to the DPP in the extern reference in the separate assembly file.

    It appears the environment always assumes a data access (which it should) and this is why the DPP is causing you an issue (you don't want this).

    If you want to jump to a variable then I would create a function pointer assigned to the data variable address and then call it (keeping everything in C). Here is an example.

    unsigned int fls_ram[50];

void (far *MyFunc)(void) = (void far *)(&fls_ram[0]);

void main (void) {

  fls_ram[0] = 0x00DB;  /* RETS instruction */

  (*MyFunc)();          /* call MyFunc in XRAM */

  for(;;);
}

    Best regards,
    Chris

  • 0 in reply to Chris Wunderlich

    Despite the DPP-addressing, the SOF-Operator shall use the 16bit-address (and this should be done with any opcode-variant).

    I was in contact with Keil and according to Support-Team this is a compiler-issue and will be solved.

    Thanks for all the help!

    Best Regards,
    Josef

  • 0 in reply to Josef Aspelmayr

    I was in contact with Keil and according to Support-Team this is a compiler-issue and will be solved.

    Seems like you've found a bug! Nice work (reporting it)!

    I was thinking it might help to explicitly declare the fls_ram variable as huge/xhuge in the C file? To make sure it doesn't use near/DPP. But this would generate the same #SOF instruction I guess, not sure.

    Regards,
    Joost Leeuwesteijn