on-chip xram

and i've got a way around the function pointer problem....

typedef void (*fun_ptr)(void);
fun_ptr xloc ;
fun_ptr MyFunc;
void main (void)
{
  s_addr=get_addr();
  xloc=(fun_ptr)s_addr;
  MyFunc=(fun_ptr) xloc;
  (*MyFunc)();
}

it works..!!

So what, exactly, is your goal here?

Why do you think you need two steps?

  xloc=(fun_ptr)s_addr;
  MyFunc=(fun_ptr) xloc;

By the way - an address in XDATA will only match an address in CODE if the board you have maps them identically, i.e. if the 32 kB of RAM have the XDATA start address 0x8000 and you have hardware that maps it into the CODE address range 0x8000 to 0xFFFF, or the RAM have XDATA start address 0 and maps into CODE space 0x0000 to 0x7FFF. If there isn't a unity mapping when the RAM is accessed as XDATA or as CODE, then you can't just do a type cast - you must then also take into account an offset.

Another thing - will your 32kB of XDATA-connected RAM map over the interrupt vectors? If not - what have you planned to do, to let a student create his own interrupt handler for a timer, UART etc?

But the huge question to ask: How can there already exist hardware for this, without these problems already having been covered? There should be documentation telling what your board can do.

It used to be a common trick on Trainers to overlay part of the code space with the XRAM. This allowed the monitor / loader program to be safe. And allowed the student to "program" the Trainer. Chips with Flash memory have made this unnecessary.

"Chips with Flash memory have made this unnecessary"

Indeed.

So, again, what is the goal of this "trainer"?

Is it for a course in computer archaeology...?!

computer archaeology
love the (here very appropiate) expression

Erik