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

Using XCROM and genarating a HEX file only for const messages

Hi,
I have a simple application such as a microcontroller having internal ROM, an ext. RAM placed from 0x8000-0xEFFF, and an EPROM placed from 0x0000 - 0x1FFF.
The EPROM is purposed to hold only display messages defined in the c code such as
char const xdata Message[] ="Hello";
I don't want to have any other code in that EPROM.
I want besides the genarated program code to have a separate HEX file for these messages ready for the EPROM. For example in format HEX-80.

How am I to configure the settings using uVison?

I have read the artıcles and the thread:
http://www.keil.com/forum/docs/thread2074.asp

Also, all related threads or similar.
However, I haven't understood: am I able to use XCONST type constants in an external memory and genarate a HEX file only containing them without having a code Banking?

So far some of my setings are as follow:
Checked boxes:
OPTIONS-Device-Use Extended Linker(LX51) instead of BL51
OPTIONS-Target-Use On Chip ROM(0x0-0xFFFF)
OPTIONS-Target-Off-chip Xdata Memory 0x8000 size 0x7000
OPTIONS-C51-Misc Controls: XCROM
OPTIONS-LX51 Locate-Use Memory Layout from Target Dialog checked
User Classes: XCONST (X:0x0000-X:0x3FFF)

Thanks in advance for your concern!

BR
Oktay

Parents
  • and an EPROM placed from 0x0000 - 0x1FFF.
    The EPROM is purposed to hold only display messages defined in the c code such as
    char const xdata Message[] ="Hello";


    As I read it

    This indicates that your EPROM is located in the DATA space, you aare trying to make tools designed to store in CODE space put data there.

    Erik

Reply
  • and an EPROM placed from 0x0000 - 0x1FFF.
    The EPROM is purposed to hold only display messages defined in the c code such as
    char const xdata Message[] ="Hello";


    As I read it

    This indicates that your EPROM is located in the DATA space, you aare trying to make tools designed to store in CODE space put data there.

    Erik

Children
  • My EPROM is located in External Memory Space NOT DATA Space.

    I use the XCROM directive to have the
    const xdata set as defined message in XDATA space but as a ROM and not requiring pre-initialisation.
    Isn't it the purpose of the XCROM directive?
    I think this is OK!

    Nothing to be surprised here.

  • and an EPROM placed from 0x0000 - 0x1FFF.
    The EPROM is purposed to hold only display messages defined in the c code such as


    My EPROM is located in External Memory Space NOT DATA Space.

    where, then are your start and interrupt vectors?

    Erik

  • "This indicates that your EPROM is located in the DATA space"

    Actually, in XDATA space.

    "you aare trying to make tools designed to store in CODE space put data there."

    No.
    This whole XCONST thing is specifically designed to put constants (which are, of course, just read-only data) into XDATA space - thus freeing-up CODE space for executable code.

    This is quite distinct from Code Banking.

  • "My EPROM is located in External Memory Space NOT DATA Space."

    Both of you are being either slack with your terminology, or just careless with your typing!

    The non-volatile storage for XCONST data needs to be located in XDATA space - that's what the 'X' means in XCONST!!

  • This whole XCONST thing is specifically designed to put constants (which are, of course, just read-only data) into XDATA space - thus freeing-up CODE space for executable code.
    If, indeed, that is so, then I presume it will be required to "burn" the XCONST EPROM separately. If it was to be stored from the code, it would occupy the same size in code.

    Erik

  • "If, indeed, that is so"

    'Course it is - would I lie to you...? ;-)

    "I presume it will be required to 'burn' the XCONST EPROM separately"

    Logically, yes.
    That's why he needs an additional OHX51 operation to strip-out the XCONST stuff into a separate Hex file; thus he should end up with a <code>.hex file created by the OH51 as part of the standard uVision build, and a <const>.hex file from the additional OHX51.

    Physically, you might actually just put the XCONST stuff into a different part of the same physical PROM chip as the CODE.
    That requires, of course, that your address decoding correctly maps the Code part of the PROM chip into the 8051's CODE space, and the Const part of the PROM chip into XDATA space...

  • That's why he needs an additional
    AH, TWO burns, now it is clear.

    Statements like
    My EPROM is located in External Memory Space NOT DATA Space.
    does not exactly make the picture very clear. "External Memory Space" is not a synanym for XDATA, most often it is used to separate internal and external code.



    Erik

  • Erik,

    Sorry for inconvinience or for misleading you!

    My purpose is:
    The code (interrupt vectors,procedures, functions and all other routines) to be in the On-Chip ROM

    The variables in the Off-chip Xdata Memory RAM from 0x8000 with size 0x7000

    And the discussed subject : constant data ,such as messagess for LCD, in a ROM which is placed in the Off-chip Xdata Memory .

    So, I need to have 2 HEX files, and the second file is not to be a Code Bank file.

    ------------------------------------------

    Using the XCROM directive and using the char const xdata I succeded to have the program assembled as I want.
    A problem occured when I run the debugger
    *** error 65: access violation at C:0x036E : no 'execute/read' permission
    which I resolved by adjusting the Memory Map for the Code Memory C:0x0, C:0xFFFF to be READ and EXECUTE.

    The last step is to achive to get, besides the main HEX code, the HEX file containing the CONST defined messages starting from address 0x0 to 0x1FFF.

    What Andrew has suggested is very close to what I want, but still not complete...

    Best regards,