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

Limited to 64k in Contiguous Mode (512k)

I'm attempting to configure a Dallas 5000 series chip to work with 512k of external memory in "contiguous mode".

Here are my memory classes, hopefully indicating a 1k spot (for my stack!) and a code/data partition at 128k:

START       END         USED      MEMORY CLASS
==========================================================
X:000400H   X:0007FFH   000400H   XDATA
X:000400H   X:0007FFH   000001H   HDATA
X:020000H   X:07FFFFH
C:001400H   C:00FFFFH   00003CH   CODE
C:001400H   C:01FFFFH   0000BBH   ECODE
C:001400H   C:01FFFFH             HCONST
Problem 1: The linker seems to be attempting to locate both my stack and variables in that first (only) XDATA segment, I suppose because I'm using the LARGE memory model? Have I specified my XDATA or HDATA incorrectly?

FWIW, my stack is defined like so:

?STACK          SEGMENT XDATA AT 0400H
                RSEG    ?STACK
                DS      1024
Since I'm using contiguous mode, I can get around this by specifying the far type in declarations, but is it necessary to do this for every variable?

Problem 2: I can't seem to actually use much of that HDATA space. I can declare up to 64k of variables, then I get the very confusing compile-time error:

error C249: 'FDATA': SEGMENT TOO LARGE
.. which makes very little sense to me. (See also another confused thread about this problem: http://www.keil.com/forum/docs/thread2733.asp.)

I can make this happen by, eg., uncommenting line 2 in the following snippet, though leaving it commented results in an error-free compile:

   char far s1[0xffff];    /* line 1 */
/* char far s2[0xffff]; */ /* line 2 */
I'm hoping someone has an idea or two - thanks very much for any help!

Parents
  • Thinking more on Problem 1, other implications past just 'annoyance' are cropping up, indicating I've probably done something wrong.

    The standard library's variables, for instance, can't all be made far, so there must be an available XDATA class made somehow.. but if my chip's partition between code and data is at 128k, how are normal (non-far, non-HDATA) variables supposed to be stored?

Reply
  • Thinking more on Problem 1, other implications past just 'annoyance' are cropping up, indicating I've probably done something wrong.

    The standard library's variables, for instance, can't all be made far, so there must be an available XDATA class made somehow.. but if my chip's partition between code and data is at 128k, how are normal (non-far, non-HDATA) variables supposed to be stored?

Children
No data