Using XCROM and genarating a HEX file only for const messages

char const xdata Message[] ="Hello";

char const xdata Message[] ="Hello";

Hi A.W.Neil,

Thanks for advise!
I have multiple C files and only 1 linker output file.
The definitions takes place in one of the C files.

I have already tried to have the CONST data HEX file by adding a command in 'After Make'
such as OHX51 lcd.obj HEXFILE (lcd.hex) H386 RANGE(0x0000-0x1FFF) OFFSET(0)
but this gave an error, as it would be expected, as lcd.obj is not an absolute object file.

So, probably I would need another 'After Make' command to have only this C file compiled and linked as absolute object file.
Am I wrong or could you advise me on how to set this up?
Thanks in advance!

BR
Oktay

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

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

OHX51 lcd.obj HEXFILE (lcd.hex) H386 RANGE(0x0000-0x1FFF) OFFSET(0)

but this gave an error, as it would be expected, as lcd.obj is not an absolute object file.

Yes. Instead of lcd.obj, you need to specify the Linker's absolute output file.
By default, uVision gives this the same name as the Project file, but with no extension.

"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

Andrew,

Thank you for your comments!
I see that you have understood my intention.

There are 2 points I am not very clear with:
1. What is the difference if I use char const xdata
instead of char const? Shall I keep the XCROM directive?
I did this as it was advised in the Example of the user guide under section XCROM.
Also, I have tried it and seems that there is no any difference in the map file.

2. Yes. Instead of lcd.obj, you need to specify the Linker's absolute output file.
By default, uVision gives this the same name as the Project file, but with no extension.

As I mentioned before, my project consists of several files and all are linked thus there exists one file containing project name as required by the OHX51. However, after running the command, this results in having the same HEX file as in the end of the general compilation.
I guess this means that I am to create a new project only for this file and compile it separately.
I don't know if there is a way to give a directive to give to the OHX51 to 'extract'
only the const variables in a separate file.
Am I wrong?
What would you advise?

Best regards,
Oktay

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,

"1. What is the difference if I use char const xdata instead of char const?"

If you include the 'xdata' keyword, you are specifically telling the compiler to put the stuff in XDATA; you don't want it in XDATA - you want it in XCONST.

Similarly, putting 'const code' would put it into CODE space instead of XCONST.

Hence, you must just put 'const' with no memory-space qualifier.

"Shall I keep the XCROM directive?"

Yes! it is the XCROM that stops the tools from putting 'const' items into CODE space!

", I have tried it and seems that there is no any difference in the map file."

The Map file should show 'const' items with a "Memory Class" of XCONST in the "MEMORY MAP OF MODULE: <you module name>" section.


"As I mentioned before, my project consists of several files and all are linked thus there exists one file containing project name as required by the OHX51."

Let's assume that your project is called "myproj"
The Linker output file (absolute object file) will be 'myproj' and the Map file will be 'myproj.map'

The absolute object file contains your code, and the constants, and the debug information (if enabled).
Note that this relies on some Keil proprietary extensions to the Object Module Format (OMF) - which is why you also need to specify the OMF2 compiler option.

When you check 'Create Hex File' in the uVision 'Output' options, it calls OH51 to extract just the code from the absolute object file, and create 'myproj.hex'

What you need to do is to add an OHX51 command to extract just the constants from the absolute object file, and create, say, 'myproj_const.hex'


"I don't know if there is a way to give a directive to give to the OHX51 to 'extract' only the const variables in a separate file."

In the XCONST Linker directive, you should have specified the XDATA address range to be used by your contstants ROM; eg,

XCONST( X:0xE000-X:0xFFFF)

RANGE( X:0xE000-X:0xFFFF )

OFFSET( -0xE000 )

Hi Andrew,

Thanks a lot!
For me the required clue was RANGE( X:0xE000-X:0xFFFF ).
It hadn't worked before for me because I used it as RANGE( 0xE000-0xFFFF ).

Yesterday, I found out that if I don't specify ?XC?LCD(X:0x0) the Debugger error keeps coming.
When I specified it like ?XC?LCD(0x0) it gave me SEGMENT errors.

In the documents' examples for such directives, the memory ranges are specified such as (0x1000 - 0x2FFF) etc. without putting the memory descriptor X:, C:, I:.
This solved my problem!

However,
I do insist that in my case using const or const xdata doesn't differ :-)
They are compiled and mapped in the same way.

Thank you for your time and help to resolve my problem!

Best regards,

Oktay Pehlivanoglu