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

Use of "Off-chip XData Memory"?

Hi,

I'm running a small testapp to see if my 80c32 uP is running fine.
Therefore, I toggle P1_0 and next to this, I'm writing a value to a var defined in external RAM.

The RAM starts at address 0x0 and is 2kB long, so the end is at 0x7FF.
I define those ranges via 'Options - Options for Target 'Target 1' - Target' - Off-chip Xdata memory.

However, I see something very strange: when I declare my variable (for fun) at a fixed location outside the given range (e.g. unsigned char xdata testvar _at_ 0x850;), then I don't get a warning, even if I'm working outside the range.
Most strange of all, the variable is written and read correctly too (I'm toggling another pin if comparison is failing and I'm observing this pin with a scope, but I don't see any toggling => value exchange seems to be correct...)!

Can't understand this...

Anyone any idea?

--Geert

Parents
  • Hi Geert and John,

    If we have a system with 2k of ram and do somthing like 'xdata char array[0x1000];' I beleive the the compiler/linker will complain that the system has insufficent memory where as Geerts fun question breaks down into two parts:-
    1. Why does addressing something above 0x7ff work in his sytem - this is because of partial address decoding and
    2. The poiter is an invalid address - why is there no warning?.
    So, I was wondering if (possibly) the only way the compiler/linker can know that 'unsigned char xdata testvar _at 0x850;' should cause a problem because there is nothing there! (ram or uart etc) would be if the compiler/linker had some way to be told where everything was?
    I would be interested in seeing if there is a simple solution that could easily pick up on typo's where a pointer is defined pointing to an address outside the system's xram address and is automatically picked up by the compiler.

    Thanks,
    Mark :-)

Reply
  • Hi Geert and John,

    If we have a system with 2k of ram and do somthing like 'xdata char array[0x1000];' I beleive the the compiler/linker will complain that the system has insufficent memory where as Geerts fun question breaks down into two parts:-
    1. Why does addressing something above 0x7ff work in his sytem - this is because of partial address decoding and
    2. The poiter is an invalid address - why is there no warning?.
    So, I was wondering if (possibly) the only way the compiler/linker can know that 'unsigned char xdata testvar _at 0x850;' should cause a problem because there is nothing there! (ram or uart etc) would be if the compiler/linker had some way to be told where everything was?
    I would be interested in seeing if there is a simple solution that could easily pick up on typo's where a pointer is defined pointing to an address outside the system's xram address and is automatically picked up by the compiler.

    Thanks,
    Mark :-)

Children
  • "I would be interested in seeing if there is a simple solution that could easily pick up on typo's where a pointer is defined pointing to an address outside the system's xram address and is automatically picked up by the compiler."

    First, you need to distinguish a pointer from a variable defined with Keil's _at_ keyword extension.

    A pointer is a standard 'C' mechanism for accessing memory addresses by indirection at run-time;
    The _at_ keyword extension is merely a way to "manually" fix the location of a variable at compile time.

    I think the assumption is that if you specify a variable's location using _at_, then you know what you're doing and take full responsibility for it.
    For other variables, you are letting the Linker/Locator do the placement in memory - therefore you want to be able to tell it how much RAM you have, and for it to be able to tell you if it can't fit everything into the space you've told it.

    You might well have some "special" memory addresses (eg, memory-mapped preipherals) that you'd want to access via _at_, but would not want to give the Linker/Locator the chance to go putting any old variables there!