LX51

LX51
Code Banking Linker/Locator

for the 8051 family
User Manual
Document version
09 February 2010
LX51
Contents
1. Introduction........................................................................................................................8
1.1 Purpose of this manual....................................................................................................................8
1.2 Scope of this manual.......................................................................................................................8
1.3 Conventions used in this manual.....................................................................................................8
1.4 Additional help or information..........................................................................................................8
2. Linker overview..................................................................................................................9
2.1 Linking.............................................................................................................................................9
2.2 Locating...........................................................................................................................................9
2.3 Segments......................................................................................................................................10
2.4 How the linker relates to other tools...............................................................................................10
2.5 Invoking and controlling the linker..................................................................................................11
2.5.1 Directives................................................................................................................................11
2.5.2 Ride7 (Raisonance Integrated Development Environment) ...................................................12
2.5.3 Command line syntax.............................................................................................................13
2.6 Input files.......................................................................................................................................13
2.6.1 Object files..............................................................................................................................13
2.6.2 Library files.............................................................................................................................13
2.7 Output files....................................................................................................................................14
2.7.1 Absolute object file..................................................................................................................14
2.7.2 Map file (Linker listing file)......................................................................................................14
2.7.3 Cross-reference file................................................................................................................15
3. Modules and segments....................................................................................................16

3.1 Modules........................................................................................................................................16
3.1.1 Symbol table...........................................................................................................................17
3.1.2 Debugging information............................................................................................................18
3.2 Segments......................................................................................................................................18
3.3 Segment naming conventions........................................................................................................18
3.4 Output module...............................................................................................................................20
3.4.1 Symbol table...........................................................................................................................21
4. Map file.............................................................................................................................22
-2-
LX51
4.1 Invocation......................................................................................................................................22
4.2 Memory model...............................................................................................................................23
4.3 Input modules................................................................................................................................23
4.4 Link map........................................................................................................................................24
4.4.1 Link map information..............................................................................................................24
4.4.2 Uses for the Link map.............................................................................................................25
4.4.3 Stack......................................................................................................................................26
4.4.4 PDATA and the external stack................................................................................................26
4.4.5 Link map title information........................................................................................................26
4.4.6 Link map examples.................................................................................................................26
4.5 Executable summary.....................................................................................................................31
4.6 Reference map..............................................................................................................................31
4.7 Symbol table..................................................................................................................................32
4.7.1 Symbol table information........................................................................................................34
4.7.2 Cross-referencing source code lines......................................................................................34
4.7.3 Locating a module’s PDATA variables....................................................................................35
4.7.4 Cross reference file................................................................................................................35
5. Segment relocation..........................................................................................................37
5.1 Segment location process..............................................................................................................37
5.2 Absolute relocation........................................................................................................................38
5.3 Ordering relocation........................................................................................................................39
5.3.1 General Memory space segment ordering..............................................................................39
5.3.2 Internal RAM segment ordering..............................................................................................39
5.4 Alignment relocation......................................................................................................................40
5.5 Memory relocation.........................................................................................................................41
5.6 Absolute segment relocation..........................................................................................................42
6. Overlaying memory..........................................................................................................43
6.1 What is overlaying?.......................................................................................................................43
6.2 Directives.......................................................................................................................................44
6.3 Map file..........................................................................................................................................44
6.3.1 Link map.................................................................................................................................44
6.3.2 Reference map.......................................................................................................................46
6.4 Function pointers...........................................................................................................................47
6.4.1 Determining the call tree.........................................................................................................47
6.4.2 Fixing the call tree...................................................................................................................47
6.4.3 Overlaying hints and tips.........................................................................................................48
-3- F
LX51
7. Code banking...................................................................................................................49
7.1 Code bank mechanism..................................................................................................................49
7.1.1 Common area.........................................................................................................................49
7.1.2 Bank switching mechanism....................................................................................................50
7.2 Code bank configuration...............................................................................................................51
7.2.1 Code bank directives .............................................................................................................51
7.2.2 Bank switching macro.............................................................................................................51
7.2.3 Assembly file..........................................................................................................................52
7.3 Map file..........................................................................................................................................53
7.3.1 Link map.................................................................................................................................53
7.3.2 Bridges...................................................................................................................................54
7.4 Locating functions and constants...................................................................................................54
7.4.1 Locating functions...................................................................................................................54
7.4.2 Locating constants..................................................................................................................54
7.5 Code banking hints and tips...........................................................................................................55
8. Flash mode......................................................................................................................56
8.1 What is Flash mode?.....................................................................................................................56
8.2 Directives.......................................................................................................................................56
8.3 Using Flash mode..........................................................................................................................56
8.3.1 Developing ROM and Flash code...........................................................................................56
8.3.2 Locking the ROM....................................................................................................................58
8.3.3 Updating the Flash Code........................................................................................................58
9. Kernel...............................................................................................................................59
9.1 Linking ..........................................................................................................................................59
9.2 Configuration.................................................................................................................................59
9.2.1 Kernel model..........................................................................................................................59
9.2.2 Time.......................................................................................................................................59
9.2.3 Clock......................................................................................................................................59
9.2.4 Dividers...................................................................................................................................60
10. Initialization, buffers and stacks.....................................................................................61

10.1 Initializing internal RAM................................................................................................................61
10.2 Printf/sprintf buffer size................................................................................................................61
10.3 External stack size.......................................................................................................................61
10.4 UART 0 initialization.....................................................................................................................62
-4-
LX51
11. Appendix A. Directives reference..................................................................................63

11.1 Relocation directives summary....................................................................................................63
11.2 Memory directives summary........................................................................................................63
11.3 Map file directives summary........................................................................................................64
11.4 Object file directives summary.....................................................................................................64
11.5 Code banking directives summary...............................................................................................65
11.6 Flash directives summary ...........................................................................................................65
11.7 Miscellaneous directives summary..............................................................................................65
11.8 ABSOLUTECODEOFFS (ABSCODEOFFS) ..............................................................................66
11.9 AMAKE (AM) ..............................................................................................................................66
11.10 BANKAREA (BANKAREA) ........................................................................................................66
11.11 BANKMAX (BANKMAX) ...........................................................................................................66
11.12 BANKMIN (BANKMIN) ..............................................................................................................67
11.13 BANKMODE (BM) .....................................................................................................................67
11.14 BIT (BI) .....................................................................................................................................68
11.15 -C...............................................................................................................................................69
11.16 CASESENSITIVE (CS) .............................................................................................................69
11.17 CODE (CO) ...............................................................................................................................70
11.18 CODESIZE (CSIZE) ..................................................................................................................70
11.19 DATA (DT) ................................................................................................................................71
11.20 DEBUGLINES (DL) ...................................................................................................................71
11.21 DEBUGPUBLICS (DP) .............................................................................................................72
11.22 DEBUGSYMBOLS (DS) ............................................................................................................72
11.23 FLASH (FLS) ............................................................................................................................72
11.24 FLASHBANKAREA (FLSBANKAREA) ......................................................................................73
11.25 FLASHNAME (FLN) ..................................................................................................................73
11.26 GLOBAL (GLB) .........................................................................................................................73
11.27 IDATA (ID) ................................................................................................................................74
11.28 INPAGE (IP) .............................................................................................................................75
11.29 IXREF (IX) ................................................................................................................................75
11.30 LINES (LI) .................................................................................................................................75
11.31 MAP (MA) .................................................................................................................................75
11.32 MEMOFFS (MO) .......................................................................................................................76
11.33 MOVEABSCODE (MAC) ..........................................................................................................76
11.34 NAME (NA) ...............................................................................................................................76
11.35 NOAMAKE (NOAM) ..................................................................................................................77
11.36 NOBRIDGE (NOBR) .................................................................................................................77
11.37 NOCASESENSITIVE (NOCS) ..................................................................................................77
11.38 NODEBUGLINES (NODL) ........................................................................................................77
-5- F
LX51
11.39 NODEBUGPUBLICS (NODP) ...................................................................................................78

11.40 NODEBUGSYMBOLS (NODS) .................................................................................................78
11.41 NODEFAULTLIBRARY (NLIB) ..................................................................................................78
11.42 NOFCTPTRMANAG (NOFPM) .................................................................................................78
11.43 NOIXREF (NOIX) ......................................................................................................................79
11.44 NOLINES (NOLI) ......................................................................................................................79
11.45 NOMAP (NOMA) ......................................................................................................................79
11.46 NOOVERLAY (NOOL) ..............................................................................................................79
11.47 NOPRINT (NOPR) ....................................................................................................................79
11.48 NOPUBLICS (NOPU) ...............................................................................................................80
11.49 NOSTATVARROM (NOSTATVARROM) ..................................................................................80
11.50 NOSYMBOLS (NOSB) ..............................................................................................................80
11.51 OVERLAY (OL) .........................................................................................................................81
11.52 PAGE (PA) ................................................................................................................................81
11.53 PDATA (PD) .............................................................................................................................82
11.54 POSTOPTI (POSTOPTI) ..........................................................................................................82
11.55 PRECEDE (PC) ........................................................................................................................83
11.56 PRINT (PR) ...............................................................................................................................83
11.57 PUBLICS (PU) ..........................................................................................................................83
11.58 RAMSIZE (RS) .........................................................................................................................83
11.59 RAMSIZEINIT (RSI) ..................................................................................................................84
11.60 REFLASH (REFLS) ..................................................................................................................84
11.61 RESERVE (RES) ......................................................................................................................84
11.62 SEGMENTOVERLAY (SO) .......................................................................................................84
11.63 STACK (ST) ..............................................................................................................................85
11.64 STARTCODE (STCO) ..............................................................................................................85
11.65 STATVARROM (STATVARROM) .............................................................................................85
11.66 SYMBOLS (SB) ........................................................................................................................85
11.67 TO (TO) ....................................................................................................................................86
11.68 XDATA (XD) .............................................................................................................................86
11.69 XDATASIZE (XSIZE) ................................................................................................................87
12. Appendix B. Ride7 Linker options reference.................................................................88

12.1 Linker settings..............................................................................................................................88
12.1.1 General.................................................................................................................................88
12.1.2 Memory.................................................................................................................................89
12.1.3 Map file (Linker listing)..........................................................................................................89
12.1.4 Startup..................................................................................................................................90
12.1.5 Bank switching, Flash mode, KR-51 Kernel .........................................................................90
-6-
LX51
12.1.6 Addition options....................................................................................................................90
13. Appendix C. Warning messages...................................................................................91
14. Appendix D. Error messages.........................................................................................94
15. Appendix E. Fatal error messages..............................................................................100
16. Conformity....................................................................................................................104
17. Glossary.......................................................................................................................105
18. Index............................................................................................................................106
19. History..........................................................................................................................107
-7- F
1. Introduction LX51
1. Introduction
The Raisonance 8051 Development Kits are a complete solution to creating software for the 8051
family of microcontrollers. The Development Kits comprise many different tools that allow projects
ranging from simple to highly complex to be developed with relative ease.
1.1 Purpose of this manual

This manual can be used by inexperienced and experienced users.
For first time users this manual describes in detail every aspect of the LX51 8051 Linker/Locator: what
a Linker/Locator is, what it does, how it relates to the other tools and how to use the Linker/Locator to
achieve various results. Armed with the knowledge in this manual, first time users will be confident and
able to configure the Linker/Locator to any application they develop.
For experienced users this manual provides appendices at the back of the manual which contain all
the Linker/Locator directives, and all warning, error and fatal error messages.
1.2 Scope of this manual

It is assumed that the user is familiar with Windows and has some familiarity with 8051
microcontrollers and the C programming language.
1.3 Conventions used in this manual

File | New Refers to the menu item “New” on the File menu.
while(1); (bold, monospaced type) User input
filename Replace the italicized text with the item it represents
[] Items inside [ and ] are optional.
[…] Represents a list of optional items that are the same as the preceding optional item.
while(1); (monospaced type) Code, Directives and software generated output
0000H or 0x0000 A Hexadecimal value
Throughout this manual the term “Linker” refers to the LX51 8051 Linker/Locator.
1.4 Additional help or information

Please visit the Raisonance website: http://www.raisonance.com/ and the forum
http://www.raisonance.com/Forum/punbb/ or contact Raisonance.
You may find additional documentation in the DOCS folder inside the Ride7 installation. In addition help
is available via the Help menu in Ride7.
Address: Raisonance S.A.S.
17, Avenue Jean Kuntzmann,
38330 Montbonnot Saint Martin
France
Telephone: +33 4 76 61 02 30
Fax: +33 4 76 41 81 68
Email: support@raisonance.com
If you find any errors or omissions, or if you have suggestions for improving this manual, please let us
know by email.
-8-
LX51 2. Linker overview
2. Linker overview
Before explaining what a Linker does, it is necessary to explain what a compiler and assembler do.
A compiler and assembler take a file containing symbolic information that represents source code.
From that source code a file is generated called an object file. This object file contains a compiled or
assembled form of the source code along with a list of the symbols used.
For example, let’s say we wrote the following C source file:
unsigned char x;
extern unsigned char y;
void main(void)
{
x = 1;
y = 2;
while(1);
}
The object file contains binary code to assign values to the variables x and y and then loop forever.
In addition a symbol table lists the variables x and y and the function main. However the locations of
x, y and main will not be known.
• In place of the addresses in the code will be place holders for the addresses.
• The code and variable are called “relocatable” as they may be located anywhere.
• Before the code can be executed and the variables used, they must be located at specific
addresses in memory.
Let's look more closely at the variable y. The C code simply tells the C Compiler that the variable is
declared elsewhere and that we wish to use the same variable y. Another C source file will declare the
variable y and will be compiled into a separate object file, however that object file is independent of this
object file. Somehow the two must be combined so the same variable y is used in both.
The two functions of the Linker are:
• locating variables and code at specific addresses,
• linking separate object files together, resolving the symbol tables in each.
In general the data represented by an object file is called a “module”.
2.1 Linking
The Linker accepts a list of object files (each containing a module).
The symbol table from each one is analysed to find out if a variable that is used in one module is
declared in another. When a match is found then the two symbols are combined into the same symbol.
This process is called “resolving”.
The same process is used for function calls. If a function or routine call is made in one module to a
function or routine declared in another module, then the symbols are resolved.
2.2 Locating
Once all the symbols have been resolved the Linker locates code and variables at specific locations,
replacing the placeholders with real addresses. Not all code and variables are relocatable however.
Some variables may have been declared using:
at 0x12 unsigned char foo;
Which means the variable foo must be located at address 12H, or otherwise generate an error.
-9- F
2. Linker overview LX51
An example of code that is not relocatable is an interrupt vector. Variables or code that are not
relocatable are called “absolute” code or variables.
Before the Linker locates the relocatable variables and code, it reserves space for the absolute
variables and code. It then locates the relocatable variables and code in the spaces around the
absolute items. The Linker therefore has to use an algorithm to generate the most efficient memory
usage.
It is also possible to use the Linker’s controls to specify that specific relocatable items must be located
at specific addresses. This method is used to locate functions.
Other Linker controls are provided to direct the Linker in general ways on how the relocatable variables
and code should be located.
2.3 Segments
Rather than the Linker locate individual variables and lines of code at a time, the compiler splits the
source files up into segments. Assembly code may be manually split up into segments.
Each segment is either absolute or relocatable and contains either multiple lines of code or multiple
variables in the same memory space. Once the segment has been located the symbol table for all the
symbols inside the segment is updated with the locations of the symbols.
Segments allow the Linker to operate faster and more efficiently and allow it to generate useful
information that may easily be read and understood by the user.
Segments are discussed in more detail in chapter 4.
2.4 How the linker relates to other tools

The following diagram shows how the Linker relates to the other tools in the toolset:
RIDE Editor
.c file .a51
file
Compiler Assembler
.obj file .obj file
.lib file
Linker Library Manager
.lib file
.aof file
Object-HEX
Converter
.hex file
RIDE Simulator/Debugger
- 10 -
The Linker accepts object files generated by the compiler or assembler. Each object file contains
absolute segments and relocatable segments.
The Linker also accepts library files. Library files contain one or more object files inside them.
Libraries can be thought of as packages or collections of object files rolled up into one new file.
A tool called the Library manager accepts object files generated by the compiler and assembler and
generates library files. The library files are then used in another project.
The absolute object file generated by the Linker is either used by a simulator/debugger or converted
into an Intel Hex file for programming into a device.
2.5 Invoking and controlling the linker
2.5.1 Directives
The Linker is a command line executable program that may be executed by entering its name – LX51 –
at the DOS prompt. Here is a sample output:
C:\>LX51
MS-DOS MCS-51 CODE BANKING LINKER/LOCATOR LX51 V5.01.02
Copyright (c) Raisonance S.A. 1987-2000. All rights reserved
***FATAL ERROR 203: EXPECTED ITEM MISSING

(NO OBJECT FILE NAME)
LINK/LOCATE RUN COMPLETE, 1 ERROR FOUND.
C:\>
It is useful for the user to be able to control the Linker and direct how it should operate to generate the
desired results for a particular application.
The executable LX51 accepts controls on the command line called “Directives” that instruct the Linker
how to operate. For example:
RAMSIZE(256)
Informs the linker that the 8051 being targeted has 256 bytes of internal RAM. The directive would be
used on the command line as follows:
LX51 foo.obj TO(foo) RAMSIZE(256)
- 11 - F
2.5.2 Ride7 (Raisonance Integrated Development Environment)

Some users prefer to use the command line, however most users prefer to use a Windows front-end to
the tool set.
The Raisonance front-end is called Ride7 and provides a point and click interface to control the Linker.
The following is a screen shot of the Ride7 Linker options window obtained by choosing Options |
Project Properties and then expanding the LX51 tree.
In Ride7 under the Linker options there is a field to enter the size of internal RAM. This field has the
same effect as the RAMSIZE directive, and it can be imagined that when Ride7 invokes the Linker it
constructs a command line with RAMSIZE on it, specifying the value entered into the field (it doesn’t
quite work that way, however the result is the same).
Ride7 does not provide graphical equivalents of all the Linker directives however. For situations when
there are no graphical equivalents, the directives can be entered into the “Additional options” field
under the Linker options exactly as if they were on a command line.
Appendix B contains tables indicating which Linker directives are used for each control in Ride7.
- 12 -
2.5.3 Command line syntax

LX51 [specialdirectiveslist] objectfilelist [directiveslist]
or:
LX51 @commandfile
specialdirectiveslist:
a space separated list of special directives. The directives may be listed in any order. If each directive
is not explicitly listed then defaults will be used for the missing directives.
Only the following two directives are special directives:
-C
objectfilelist:
a comma separated list of object files and library files to be linked together.
directiveslist:
a space separated list of directives. The directives may be listed in any order. If each directive is not
explicitly listed then defaults will be used for the missing directives. Please refer to the directives
reference in Appendix A for the default setting for each directive. Special directives may not be listed in
this section of the command line.
commandfile:
a plain text file that contains the command line arguments. I.e. the special directives, object files and
directives. The arguments may be split into multiple lines by adding an ampersand (&) to the end of the
lines. The ampersand allows to add comments after it on the line.
Command line examples:
LX51 -C test.obj, foo.lib TO(test.aof) RS(128) IX
LX51 @test.cmd
Where test.cmd contains:
-C test.obj, foo.lib &
TO(test.aof) & comments: this allows to specify the .aof name
RX(128) IX
2.6 Input files
2.6.1 Object files

The object files are generated by the compiler or assembler and contain segments, a symbol table and
debugging information. Each segment may be absolute or relocatable. The Linker resolves the
symbols in all the Modules involved in Linking and then locates the segments in the memory map
according to the internal algorithms and the controls provided by the user.
The format of the object file is OMF-51.
The usual filename extension for the object files is “.obj”.
2.6.2 Library files

Library files are one or more object files grouped together into a new file called a library. The Library
Manager allows creation of libraries and addition of object files to them.
The usual filename extension for library files is “.lib”.
- 13 - F
2.7 Output files
2.7.1 Absolute object file

The result of the linking and locating process is a single absolute object file. This file contains absolute
segments, a symbol table and debugging information.
• All data and code inside the object file is located at a specific address.
• The data represented by the absolute object file is also called a “Module”.
• The absolute object file may be used by the debugger/simulator to either debug the code on the
target hardware, or simulated to verify correct operation without the need for any hardware.
• Once the project is finalized the absolute object file may be converted into an Intel Hex file,
which is the file format accepted by virtually all device programmers.
• The format of the object file is OMF-51.
• The usual filename extension for the absolute object file is “.aof”.
2.7.2 Map file (Linker listing file)

The map file is a text file generated by the Linker that describes various aspects of the linking and
locating operation. Its contents are invaluable for debugging applications and the contents of the file
are discussed in detail in Chapter 5. The map file contains the following information:
Map file item Description
Invocation How the Linker was invoked, including all the controls used.
Memory Model Compiler Memory Model used for the application.
Input Modules A list of all the input Modules involved in the Linking.
Link map Memory map of the application, showing where every segment was located.
Executable Summary Memory requirements for the application.
Reference map Call tree, showing which functions are called and by who. It also shows
where a function’s automatic variables are overlaid.
Symbol Table A table of all the symbols (public, local and lines) in the application.
There are various controls (called Directives) that may be used to control the contents of the map file:
Map file directive Description
LINES (LI) Insert source code lines into the symbol table.
MAP (MA) Include a Link map in the map file.
NOLINES (NOLI) Omit source code lines from the symbol table.
NOMAP (NOMA) Omit a Link map from the map file.
NOPRINT (NOPR) Stops the Linker from generating a map file.
NOPUBLICS (NOPU) Omit public symbols from the symbol table.
NOSYMBOLS (NOSB) Omit local symbols from the symbol table.
PRINT (PR) Instructs the Linker to generate a map file.
PUBLICS (PU) Insert public symbols into the symbol table.
SYMBOLS (SB) Insert local symbols into the symbol table.
- 14 -
The map file is sometimes referred to as the Linker listing file. However this manual refers to the file as
the map file to differentiate it from the listing files generated by the compiler and assembler.
2.7.3 Cross-reference file

The Linker can be instructed to generate a Cross-reference file by using the directive IXREF.
The Cross-reference file contains a symbol table that indicates in which module a symbol is declared
and in which modules the symbol is used. The Cross-reference file can be useful to verify that the
Linker resolved symbols as you expected and is provided as an aid to debugging.
The usual filename extension for the Cross-reference file is “.xrf”.
- 15 - F
3. Modules and segments LX51
3. Modules and segments

The following diagram graphically represents the relationship between a source file, an object file, a
module and segments.
Source File .c file
Compiler or Assembler
Modul
Segment Segment e
Segment Segment .obj

file
Symbol Debug info*
Table
* optionally
included
3.1 Modules
A single source file is either compiled or assembled to generate an object file, which contains data
collectively referred to as a Module.
The Module has a name that is derived from the source file name. For example the source file FOO.C
will generate a module with the name FOO.
Note: Each Module in a project must have a unique name. This creates implications for the source file
names used in a project. For example:
FOO.C
FOO.A51
Both generate Modules with the name FOO. The Module names will therefore not be unique in the
project. The result is that a project cannot have two source files with the same file name regardless of
the extension used.
This problem can be avoided by using the assembler’s NAME directive, which allows the Module name
to be explicitly chosen by the user. The Module name can be unrelated to the file name.
Another implication is that debugging is made easier if source files have descriptive file names. It will be
clear what function a particular module has.
The data contained inside the module consists of:

• One or more segments
• A symbol table
• Optional debugging information
Segments are discussed in the next section.
- 16 -
LX51 3. Modules and segments
3.1.1 Symbol table

The symbol table contains all the symbols referred to in the segments. They are:
• Symbols local to the module
• Symbols that may be shared with other modules
Examples of symbols are:
• Function names
• Variable names
• Pointer names
• Structure/Union names
• Structure/Union members
An idea of the information included in the symbol table may be seen in a compiler or assembler listing
file. Here is an example:
NAME CLASS MSPACE TYPE OFFSET SIZE
==== ===== ====== ==== ====== ====
s. . . . . . . . . . . . . . . STATIC DATA U_CHAR 0000H 1

g. . . . . . . . . . . . . . . PUBLIC DATA U_CHAR 0001H 1
st . . . . . . . . . . . . . . * TAG * ----- STRUCT ----- 2
m1 . . . . . . . . . . . . . MEMBER ----- U_CHAR 0000H 1
m2 . . . . . . . . . . . . . MEMBER ----- U_CHAR 0001H 1
mystruct . . . . . . . . . . . PUBLIC DATA STRUCT 0002H 2
pst. . . . . . . . . . . . . . PUBLIC DATA PTR 0004H 3
main . . . . . . . . . . . . . PUBLIC CODE PROC ----- -----
a?041. . . . . . . . . . . . . AUTO DATA U_CHAR 0000H 1
The example shows that for each symbol several pieces of information are stored. They are:
Class
The symbol classification such as PUBLIC for symbols that are shared between modules, STATIC for
symbols local to a module, EXTERN for symbols declared in another module, AUTO for symbols local
to a block, MEMBER for symbols that are structure or union members and * TAG * for symbols that are
name of structure or unions.
Mspace
The memory space the symbol is stored in. For example functions are stored in the code memory
space. Structure declarations do not result in the allocation of memory so they do not have a memory
space.
Type
Indicates the type of the symbol. Examples are U_CHAR for unsigned character, PTR for pointer,
PROC for functions and STRUCT for structures.
Offset
For each memory space the symbols are sequentially arranged in memory with an offset. For example
the first symbol in DATA space will be at offset 0000H. The second symbol will be sequentially located
after the first symbol, so would be located at offset 0002H if the type of the first symbol were an int.
For structure or union members the offset is the offset from the start of the structure or union. For
example the first member will have an offset of 0000H.
Size
The size in bytes required for storage of the symbol. For example a char requires one byte.
- 17 - F
3.1.2 Debugging information

The debugging information is optionally included in a module. Compiler and assembler controls allow
the user to determine if the information is included.
The Linker does not use the debugging information, however it places the information in the output
module so it may be used by debuggers and simulators to provide high-level and symbolic debugging.
The debugging information includes:
• Source code line numbers that correspond to sections of generated binary code
• Variable information
• Structures/Unions information
• Pointer information
• Locations of variables that are stored in registers
3.2 Segments
The code and data generated by a source file is split up into segments. As already explained, these
segments, along with a symbol table and optional debugging information are referred to as a module.
But how is the source code split up into segments?
From each source file there will be created one segment for each function and one segment for each
for of the memory spaces DATA, IDATA, BIT, CODE, PDATA and XDATA, providing there are
variables in a particular memory space.
For example, if a module has the following:
• Two functions foo and bar
• Three variables in DATA memory
• Two variables in XDATA memory
Then the following four segments will be created:
• One for the function foo
• One for the function bar
• One for the variables in DATA memory
• One for the variables in XDATA memory
3.3 Segment naming conventions

Each segment may be relocatable or absolute. Inside relocatable segments is code or variables that
may be located by the Linker. Inside absolute segments is code or variables that have already been
allocated fixed memory locations.
Each relocatable segment is given a unique name that is derived from its contents and the module it is
created from.
Note: Absolute segments do not have names because the OMF-51 file format used for the object files
does not allow names for absolute segments.
CODE segments fall into two categories, executable and non-executable. The non-executable code
segments have the same naming format as other non-executable segments containing variables in the
other memory spaces. Executable code segments have a different naming format.
Executable code segment names have the following format:
?PR?symbolicfunctionname?modulename
Where symbolicfunctionname is a symbol used to represent the function throughout the Linker
map file and Cross Reference file (described in chapter 4).
It has the following format:
[_|?]functionname
- 18 -
Where:
• “_” prefix means a non-re-entrant function whose parameters are passed in registers
• “?” prefix means a re-entrant function whose parameters are passed in registers
For example the following functions declared in the module CRUNCH:
void apple(void) { ; }
void banana(unsigned char b) { ; }
void orange(void) reentrant { ; }
void pear(unsigned char p) reentrant { ; }
Generate the following segment names:
?PR?apple?CRUNCH
?PR?_banana?CRUNCH
?PR?orange?CRUNCH
?PR??pear?CRUNCH
Non-executable segment names have the following format:
?memoryspace?module name
Where memoryspace is one of:

• DT – DATA
• BI – BIT
• ID – IDATA
• XD – XDATA
• PR – CODE
• PD – PDATA
For example the DATA variables in the module MAIN will be placed in a segment called:
?DT?MAIN
and the code constants in the module TRAM will be placed in a segment called:
?PR?TRAM
- 19 - F
3.4 Output module

The following diagram shows the files input into the Linker and the file generated, represented as
modules.
Library
Module Module
.obj .obj .lib
Linker
.aof
Module
As shown in the diagram, whether the input files are object files or library files, the result is that a
collection of modules is supplied to the Linker.
The Linker then takes the symbol tables of each module and resolves them. The relocatable segments
are located according to the rules and algorithms used by the Linker.
Generated by the Linker is an Output module, stored in a absolute object file (extension .aof). All the
segments in the Output module are absolute. In addition all the symbols in the symbol table have fixed
addresses. As in the case for the Input modules, the debugging information is optional.
The name of the Output module is by default the same as the name of the first module supplied to the
Linker. However the Linker NAME directive allows the name of the Output module to be selected by the
user. This can be useful when debugging or simulating applications.
- 20 -
3.4.1 Symbol table

The map file generated by the Linker includes a textual version of the symbol table that is included in
the Output module. The following is an example:
VALUE TYPE NAME
----- ---- ----
------- MODULE main
C:0000H SYMBOL _ICE_DUMMY_
C:8006H PUBLIC main
D:0011H PUBLIC pst
D:000FH PUBLIC mystruct
D:000EH PUBLIC g
D:000DH SYMBOL s
C:8006H LINE# 12
C:8006H LINE# 12
C:8006H LINE# 15
C:8006H LINE# 16
------- ENDMOD main
C:0003H PUBLIC ?C_START1
C:8008H PUBLIC ?C_INITSEGSTART
N:0003H PUBLIC IDATALEN
N:00FFH PUBLIC _INITP2?
A detailed analysis of the symbol table is given in section 5.7. The symbol table contains the symbol
name, type and location. The symbols are grouped into modules.
As explained in section 5.7 this symbol table is essential for finding out where variables and functions
were located.
- 21 - F
4. Map file LX51
4. Map file
The map file is generated by the Linker and contains a wealth of information on what the Linker actually
did to the segments in the Input modules. Understanding the map file can speed up development time
and greatly improve the chances of a project’s success.
The map file usually has the file name extension .m51 and is a plain text file. It is generated during the
Linker’s execution and placed in the project directory.
The PRINT and NOPRINT directives instruct the Linker to either generate or not generate a map file
respectively. The default setting is for the Linker to generate the map file and it is recommended that
the map file is always generated.
The map file contains the following sections of information in order from start to finish. Each section is
discussed in detail in the remainder of this chapter.
Map file item Map file description

Invocation How the linker was invoked, including all the controls used.
Memory model The compiler Memory Model used for the application.
Input modules A list of all the input modules that were involved in the linking.
Link map The memory map of the application, showing where every segment was located.
Executable summary The memory requirements for the application.
Reference map The call tree, showing which functions are called and by who. It also shows where
a function’s automatic variables are overlaid.
Symbol table A table of all the symbols (public, local and lines) in the application.
4.1 Invocation
The first item in the map file shows how the Linker was called on the command line, or if Ride7 was
used to call the Linker, then how it could have been called on the command line to achieve the same
result. This is very useful in determining if a mistake was made with the Linker options in Ride7 or on
the command line, or if finding out if a particular directive was or was not used.
It is also useful for finding out which directives are controlled by specific Linker options in Ride7.
Here is an example:
LX51 c:\temp\testproject\main2&
.obj,c:\temp\testproject\main.obj TO(c:\temp\testproject\project.AOF) PR(c:\t&
emp\testproject\project.m51) PW(80) RS(128) RSI(4) IX
The ampersands (&) at the end of some of the lines indicate that an argument has been split across
that line and the following line for the sake of formatting the map file.
The above example clearly shows the paths and file names of the object files that were linked together,
the location and file name of the absolute object file generated, the location and file name of the map
file, and the directives used.
When debugging an application the command line invocation makes it possible to look up all the
directives used in the reference section of this manual, to ensure that the Linker is being invoked
correctly.
- 22 -
LX51 4. Map file
4.2 Memory model

The Memory Model line in the map file indicates which compiler Memory Model the project was built
with, and if floating point was used anywhere in the project. Here is an example:
MEMORY MODEL: SMALL WITHOUT ANY FLOATING POINT ARITHMETIC
This information is useful for confirming the desired memory model was used. If the Linker correctly
determined the Memory Model then the correct libraries would have been linked in.
4.3 Input modules

The compiler employs pre-written library routines to perform some common operations. These include:
• Floating-point arithmetic
• Indirect access via generic pointers
• Some integer arithmetic
• Standard library routines
• Startup code
When the Linker executes it recognizes that various library routines are being called. It locates and
includes in the link process the relevant modules from libraries supplied with the toolset.
This operation is all transparent to the user, however the map file includes a list of all the Input modules
involved in the link process, including modules in libraries. The following is an example:
INPUT MODULES INCLUDED
C:\TEMP\TESTPROJECT\MAIN2.OBJ(MAIN2)
C:\TEMP\TESTPROJECT\MAIN.OBJ(MAIN)
c:\RIDE\ride\Lib\RC51FPS.LIB(MULTIEEE)
c:\RIDE\ride\Lib\RC51FPS.LIB(TOOLIEEE)
c:\RIDE\ride\Lib\RC51S.LIB(C3S)
c:\RIDE\ride\Lib\RC51S.LIB(MV_XD2RG4)
c:\RIDE\ride\Lib\RC51S.LIB(_C_IDATALEN)
Each line has the following format:
ObjectFileorLibraryFileContainingModule (Modulename)
For example the first line indicates that the object file MAIN2.OBJ was linked, containing the module
MAIN2. It also shows that from the library file RC51FPS.LIB, the modules MULTIEEE and TOOLIEEE
were linked in because the compiler generated code that made calls to routines in those modules.
Library names have the following format: RC51[FP]memorymodel.LIB
If FP is present in the library name then it contains the routines for manipulation of floating point
numbers.
If FP is not present in the library name then it contains the routines for startup code, standard libraries,
accesses via generic pointers, etc.
Where memorymodel: is one of:
<memory model> Library for

T Tiny Memory Model
S Small Memory Model
L Compact, Large and Huge Memory Models
- 23 - F
4. Map file LX51
4.4 Link map

The Link map is a representation of the Memory map of the project. It is divided up into the
DATA/IDATA, XDATA and CODE memory areas, and each area contains a list of segments in order.
Here is an example:
LINK MAP OF MODULE: C:\TEMP\TESTPROJECT\PROJECT.AOF (MAIN2)
TYPE BASE LENGTH RELOCATION SEGMENT NAME

---- ---- ------ ---------- ------------
* * * * * * * DATA/IDATA M E M O R Y * * * * * * *
REG 0000H 0008H ABSOLUTE "REG BANK 0"
DATA 0008H 0001H UNIT ?DT?MAIN2
0009H 0017H *** GAP ***
BIT 0020H.0 0000H.2 UNIT ?BI?MAIN2
0020H.2 001FH.6 *** GAP ***
DATA 0040H 0001H ABSOLUTE
IDATA 0041H 0001H * * STACK * * _STACK
* * * * * * * PDATA/XDATA M E M O R Y * * * * * * *
XDATA 0000H 0001H UNIT ?XD?MAIN2
PDATA 0001H 0001H INPAGE ?PD??C_XSTACK
* * * * * * * CODE M E M O R Y * * * * * * *
CODE 0000H 0003H ABSOLUTE
CODE 0003H 0003H UNIT ?PR?bar?MAIN2
CODE 0006H 0002H UNIT ?PR?MAIN
0008H 0003H *** GAP ***
CODE 000BH 0003H ABSOLUTE
CODE 000EH 000FH UNIT ?PR?C51_STARTUP?
CODE 001DH 0005H UNIT ?PR?isr?MAIN
CODE 0022H 0004H UNIT ?PR?foo?MAIN
CODE 0026H 0005H UNIT ?PR?main?MAIN
Each line contains information about a single segment or contains a gap.

The segments are listed in memory order for each memory space, with the segment at the lowest
address at the top and the segment at the highest address at the bottom.
4.4.1 Link map information

The memory locations that segments occupy must be read carefully. For example this segment::
does not occupy locations 0008H and 0009H, because that would make it two bytes in size. It occupies
location 0008H only. It is important to remember that the first location a segment occupies is the
location given as the base address, not the first location after the base address.
- 24 -
LX51 4. Map file
The following is a description of each piece of information contained in a single line.

Information Description
Type The memory type of the segment or REG if it is a Register Bank. Gaps do not have
a memory type. This is required because DATA, BIT and IDATA segments share
the same memory space.
Base The start address of the segment. If the start address is not byte aligned then the
address is in the format: byteaddress.bitposition
for example 0020H.4 is byte 0020H plus 4 bits.
Length The length of the segment. If the length is not a whole number of bytes then the
length is in the format: bytes.bits
For example 0001H.3 is a length of 1 byte and 3 bits.
Relocation Whether the segment is absolute (ABSOLUTE) or relocatable (UNIT, INPAGE).
Gaps do not have a relocation type.
Segment Name The name of the segment. Absolute segments do not have names. Gaps also do
not have names. Register Bank segments, although absolute, are given names for
descriptive purposes, which appear inside quote marks.
4.4.2 Uses for the Link map

The Link map indicates two important pieces of information about how the segments were located:
1. What part of the project was located where. It is clear to see from the example Link map given
that the main function is located starting at 0026H in the CODE memory space. It is also clear to
see that the static DATA variables from the module MAIN2 (which is generated from MAIN2.C)
are located starting at 0008H.
2. Which sections of memory are actually used. The Link map makes it easy to identify gaps and
calculate the highest address used in each memory space. The example Link map shows a gap
starting at 0009H in DATA space that is 17 bytes in length.
The first free location in a particular memory space is calculated using the following method:
The base address of the last segment listed plus the length of the last segment listed.
For example, in the example Link map the last segment listed for the CODE space is:
Therefore the first free location in CODE space is 0026H + 0005H = 002BH.
The Link map also provides an aid to locating specific variables in the symbol table. That will be
discussed in the Symbol Table section of this chapter.
There are two absolute segments shown in the example Link map that are both three bytes in size.
Because an LJMP instruction occupies three bytes, absolute segments that are three bytes in size are
usually interrupt vectors or the reset vector. In the example Link map the absolute segment at 0000H is
the reset vector. The other segment is located at 000BH, which is an interrupt vector address.
If, for some reason, the interrupt service routine in a project is not being vectored to when it should be,
looking at the Link map for an absolute segment, three bytes in size at the correct vector address is an
easy way of ensuring the interrupt has been declared properly in the source code.
The Linker provides controls to absolutely located relocatable segments. For example:
CODE(?PR?foo?MAIN(0x100))
forces the Linker to try and locate the segment ?PR?foo?MAIN at location 0100H in CODE space.
Usually there is a very good reason for locating segments in specific locations, and the project may not
work if they are not where they need to be located. The Link map may be checked to ensure the
segments were located in the correct place.
- 25 - F
4. Map file LX51
4.4.3 Stack
The stack segment is always located last in the IDATA memory space and has the special segment
name _STACK.
However, you may have noticed that the stack segment is only one byte in size. The reason for this is
because the stack segment only represents the stack pointer’s initial location, not the whole stack.
Just before the main function is executed, the system stack pointer will be set to the address of the
stack segment.
As data is pushed onto the stack the stack pointer moves upwards through the IDATA space. If it ever
goes beyond 7FH (for 128 bytes of IDATA) or FFH (for 256 bytes of IDATA) it will either access
gibberish or wrap around to 00H. In either situation the application will quickly crash.
In the example Link map the stack segment is located at 0041H in IDATA. At first it appears that the
rest of IDATA (0042H – 007FH or 00FFH) is free for use by variables or pointers, perhaps as a scratch
space. Wrong!
Let's say that the biggest the stack will ever get at any point in time is 20H bytes. If any location
between 0042H and 0042H + 20H – 1 = 0061H is modified, there is a big risk that data on the stack will
be corrupted resulting in the application crashing.
This has other implications. Let's say your microcontroller has 128 bytes of RAM and the Link map
looks like the example shown. Also let's say that your application at most requires 20H bytes for the
stack. This leaves 0080H – 0041H – 0020H = 1FH bytes of IDATA that is never used.
Now let's imagine that you make a modification to the application. The modification includes an array
that is 11H bytes in size. The result of the modification means that the stack could now become 30H
bytes in size at any point in time. Now the stack will be located at 0041H + 11H = 0052H. The amount
of IDATA that will never be used is now: 0080H – 0052H – 0030H = -2 bytes!
At some point the stack will overflow crashing the application. The Link map does not inform you of this
fact directly, only indirectly.
4.4.4 PDATA and the external stack

It is possible to configure the compiler to use a simulated external stack, both for re-entrant functions
and in place of the system stack. The external stack is accessed as PDATA memory and therefore has
a maximum size of 256 bytes. The external stack is therefore a PDATA segment, 256 bytes in size (it
is also possible to configure the stack size in the compiler options).
The external stack segment has the name ?PD??C_XSTACK.
Note: Both PDATA variables and the external stack have to share the same 256 byte page. However
PDATA variables are located before the external stack, therefore it may not be possible to allocate as
much space as desired for the external stack. For example if the external stack is set to a size of 256
bytes and there are four bytes of PDATA variables in the project, then the external stack will be 252
bytes in size. If this causes a problem for your project then move some variables from PDATA to another
memory space to free up more of the page.
4.4.5 Link map title information

The title of the Link map contains the path and file name of the generated absolute object file, along
with the name of the Output module in parentheses.
4.4.6 Link map examples

The section contains 4 link map examples.
- 26 -
LX51 4. Map file
Link map Example 1

The following example Link map shows all CODE segments starting at location 8000H. This is a typical
arrangement when a von Neumann memory architecture is being used or two applications must share
the same memory map.

---- ---- ------ ---------- ------------
0009H 0037H *** GAP ***
DATA 0040H 0001H ABSOLUTE
* * * * * * * CODE M E M O R Y * * * * * * *
0000H 8000H *** GAP ***
8008H 0003H *** GAP ***
As the Link map makes clear, there is a gap starting at 0000H in CODE space, 8000H bytes in size.
Therefore the gap covers locations 0000H to 7FFFH inclusive.
Note: By using the ABSOLUTECODEOFFS directive, the reset vector and interrupt vectors can also be
located starting at 8000H. So the interrupt vector previously at 000BH is now located at 800BH. This is
useful if the physical memory device exists at 8000H, however is mapped to logical addresses starting at
0000H.
- 27 - F
4. Map file LX51
Link map Example 2

The example Link map shown here is of an application that uses Register Banks zero, two and three.

---- ---- ------ ---------- ------------
0009H 0007H *** GAP ***
* * * * * * * CODE M E M O R Y * * * * * * *
0008H 0003H *** GAP ***
CODE 0025H 000BH UNIT ?PR?foo?MAIN
Notice that the Linker has inserted a DATA segment into the eight byte space between Register Banks
zero and two to optimize memory usage and leave as much room as possible free for the stack.
- 28 -
LX51 4. Map file
Link map Example 3

The following example Link map shows that Code Banking is used by the application.

---- ---- ------ ---------- ------------
DATA 0008H 0001H UNIT ?DT?BANK?SWITCH
IDATA 000AH 0001H * * STACK * * _STACK
* * * * * * * CODE M E M O R Y * * * * * * *
CODE 0003H 0035H INBLOCK ?BANK?SWITCH
CODE 0038H 000FH UNIT ?PR?C51_STARTUP?
CODE 004DH 0005H UNIT ?PR?main?MAIN
* * * B A N K N U M B E R 0 * * *
* * * * * * * CODE M E M O R Y * * * * * * *
CODE 8000H 0002H UNIT ?PR?bank2?MAIN3
CODE 8002H 0004H UNIT ?PR?_crunch?MAIN3
* * * B A N K N U M B E R 1 * * *
* * * * * * * CODE M E M O R Y * * * * * * *
The first CODE memory section shows the CODE segments that are located in the common area.
The other two CODE memory sections are listed under BANK NUMBER 0 and BANK NUMBER 1 and
show the CODE segments that are located in code banks zero and one respectively. The code banks
start at location 8000H.
- 29 - F
4. Map file LX51
Link map Example 4

When Flash mode is being used the Link map will look something like the following example:

---- ---- ------ ---------- ------------
DATA 0008H 0005H UNIT ?Reserve?DATA
DATA 000DH 0001H UNIT ?DT?BANK?SWITCH
DATA 000EH 0001H UNIT ?DT?MAIN2
000FH 0011H *** GAP ***
DATA 0020H 0008H BITADDRESSABLE ?Reserve?BDATA
BIT 0028H.0 0000H.4 UNIT ?Reserve?BIT
0028H.4 0000H.4 *** GAP ***
* * * * * * * CODE M E M O R Y * * * * * * *
CODE 0003H 0001H UNIT _C_INITD?CD
CODE 0004H 0072H UNIT ?PR?C51_STARTUP?
CODE 0076H 0026H UNIT ?BANK?SWITCH
CODE 009CH 0002H UNIT ?PR?MAIN
CODE 009EH 0004H UNIT ?PR?foo?MAIN
CODE 00A2H 0005H UNIT ?PR?main?MAIN
* * * F L A S H A R E A * * *
* * * * * * * CODE M E M O R Y * * * * * * *
CODE 8000H 0009H ABSOLUTE ?FLASH?TABLE_00?
CODE 8009H 0002H UNIT ?PR?bank2?MAIN3
CODE 800BH 0004H UNIT ?PR?_crunch?MAIN3
CODE 800FH 0003H UNIT ?PR?bar?MAIN2
The CODE memory section listed under FLASH AREA shows which CODE segments will be located in
Flash memory.
The Flash option also allows DATA memory to be reserved. Special absolute segments are generated
to ensure those memory areas are not used with the following segment name format:
?Reserve?memorytype
- 30 -
LX51 4. Map file
4.5 Executable summary

The executable summary describes the total internal RAM, external RAM and CODE space usage for
a project, both in hexadecimal and decimal values. For example:
Total INTERNAL RAM storage requirement: 0018H.4 (24.4)
Total EXTERNAL RAM storage requirement: 0101H (257)
Total CODE storage requirement: 00BCH (188)
Note: Summary does not include dynamic stack requirements
The values are given in the following format: bytes.bits, for example 18H.4 and 24.4 both mean 24
bytes and four bits.
The executable summary however, does not always give a full picture of the memory requirements of
an application. When code banking is used the sizes of all the code segments in all the code banks
used along with the common area are totaled and presented in the executable summary, even though
some segments occupy the same locations, just in different code banks.
In addition, the summary does not include the system stack, as the compiler is unable to determine
how much stack space would be required by the application.
4.6 Reference map

The Reference map shows the call references that the Linker determined from the structure of the
code and which functions had variables that were overlaid, and where they were overlaid. The following
is an example:
SEGMENT BI_GROUP DT_GROUP XD_GROUP
+--> CALLED SEGMENT START LENGTH START LENGTH START LENGTH
---------------------------------------------------------------------------------
?PR?_emSend?EMMICRO --------------- --------------- 016FH 000BH
+--> ?PR?_emByteGet?EMMICRO
+--> ?PR?PacketSend?EMSERIAL
?PR?_emByteGet?EMMICRO --------------- --------------- 017AH 0008H
?PR?PacketSend?EMSERIAL --------------- --------------- ---------------

+--> ?PR?PacketHandler?EMSERIAL
+--> ?PR?_SysPutch?USART
?PR?PacketHandler?EMSERIAL--------------- --------------- 017AH 0003H

+--> ?PR?SysRxBufferNotEmpty?USART
+--> ?PR?SysGetch?USART
+--> ?PR?_emCrcStr?EMMICRO
+--> ?PR?SysTxBufferNotFull?USART
+--> ?PR?SysTxClear?USART
+--> ?PR?_SysPutch?USART
+--> ?PR?_emCrcChar?EMMICRO
Every executable segment in the project has a line in the Reference map. On that line there are the
following items:
- 31 - F
4. Map file LX51
Item Reference map description

SEGMENT Segment name with segments it calls listed below.
BI_GROUP Start and end address of any overlaid automatic BIT variables used by the segment.
DT_GROUP Start and end address of any overlaid automatic DATA variables used by the segment.
XD_GROUP Start and end address of any overlaid automatic XDATA variable used by segment.
In the example the segment ?PR?_emSend?EMMICRO contains function calls to the segments listed
below it, which are ?PR?_emByteGet?EMMICRO and ?PR?PacketSend?EMSERIAL.
The segment also contains overlaid automatic variables that are located in the XDATA memory space.
They start at location 016FH and total 000BH bytes in size. Somewhere else in the Reference map
there will be another segment with overlaid automatic variables, the start address and length of which
result in an overlap with the overlaid variables of this segment. Overlaying Memory is discussed in
chapter 7.
If we look at those locations in the Link map we will see something like:
* * * * * * * XDATA M E M O R Y * * * * * * *
XDATA 0152H 0032H UNIT _XGROUP03_
_XGROUP03_ is a special segment name, which means that it contains overlaid variables.
The Linker can automatically determine where indirect function calls are made and generated the
appropriate Reference map. The Reference map does not distinguish between direct and indirect
function calls.
4.7 Symbol table

The symbol table lists information on the following types of symbols:
• Public symbols – symbols available for use by more than one module
• Regular symbols – symbols only available to one module
• Source code line numbers
The following Linker directives allow selection of which types of symbols are included in the symbol
table. By default, all types are included.
Directive Symbol table directives description
LINES Includes source code lines in the symbol table
PUBLICS Includes public symbols in the symbol table
SYMBOLS Includes regular symbols in the symbol table
NOLINES Excludes source code lines from the symbol table
NOPUBLICS Excludes public symbols from the symbol table
NOSYMBOLS Excludes regular symbols from the symbol table
Note: Regular symbols include static symbols and automatic symbols. Due to limitations in the OMF-51
file format used, the information that differentiates between static and automatic symbols is lost. Hence
both symbols are referred to at the Linking stage as Regular symbols. This is also the reason why the
symbol type is listed in the table rather than the symbol class. Because some information has been lost,
it cannot be referred to as the class, only as the symbol type, to emphasize the difference between the
information in the compiler generated Symbol Table and the Linker generated Symbol Table.
- 32 -
LX51 4. Map file
Here is an example symbol table containing all three types of symbols:

SYMBOL TABLE FOR C:\TEMP\TESTPROJECT\PROJECT.AOF(MAIN)
-------------------------------------------------------
VALUE TYPE NAME
----- ---- ----
------- MODULE main
C:008BH PUBLIC main
C:0077H PUBLIC foo
D:0033H PUBLIC funcptr
C:006AH PUBLIC bar
D:0032H PUBLIC x
C:0069H PUBLIC y
D:0031H PUBLIC p
D:0030H SYMBOL s
------- PROC bar
D:0008H SYMBOL m
C:006AH LINE# 12
C:0076H LINE# 18
------- ENDPROC bar
------- PROC foo
D:0008H SYMBOL m
C:0077H LINE# 20
C:0077H LINE# 24
C:008AH LINE# 29
------- ENDPROC foo
------- PROC main
C:008BH LINE# 31
C:0091H LINE# 36
------- ENDPROC main
------- ENDMOD main
C:0003H PUBLIC ?C_START1
C:0093H PUBLIC ?C_INITSEGSTART
N:0003H PUBLIC IDATALEN
N:00FFH PUBLIC _INITP2?
The table is divided up into modules. Each module starts with the line:---- MODULE <module
name>
and ends with the line:----- ENDMOD <module name>
Inbetween the module start and end lines, symbols declared in the module are listed along with source
code lines. The source code lines are grouped into functions.
Each function starts with the line:----- PROC <function name>
and ends with the line: ----- ENDPROC <function name>
There are also some symbols declared in library code that are not listed in-between module start and
end lines. These symbols are included at the end of the Symbol Table.
- 33 - F
4. Map file LX51
4.7.1 Symbol table information

The following is a description of each piece of Symbol Table information contained in a single line.
So, from looking at the example, the symbol p is a Public Symbol located at 0031H in DATA memory.
Information Description
Value Memory location that the symbol is equivalent to. The memory location is in the format:
memoryspace:address
Where memoryspace can be:
• C – CODE
• D – DATA
• B – BIT
• I – IDATA
• X – PDATA/XDATA
• N – any memory space
Type Type of the symbol.

• PUBLIC – Public Symbols
• SYMBOL – Regular Symbols
• LINE# – Source code lines
Name Symbol name for Public and Regular Symbols. Source code line number for source
code lines.
4.7.2 Cross-referencing source code lines

In the example Symbol Table, inside the function foo, source code line number 20 is located at 0077H
in CODE memory. The function foo is inside the module main.
If we look at the compiler generated listing file for the source file main.c (which generated the module
main) there is a section where the source code is listed. To the left of each source code line there is a
line number. If we look at line 20 it reads:
20 void foo(void)
therefore located at 0077H in CODE memory is the start of the function foo.
Now, if we look back at the Symbol Table, notice that source code line 24 is also located at 0077H in
CODE memory. How can this be possible? Look at source code lines 20 through 24 in the compiler
listing file:
20 void foo(void)
21 {
22 1 unsigned int m[20];
23 1
24 1 m[5] = x;
Line 24 is the first line in the function foo that actually does something. It is not necessary to generate
any code for the start of the function or the declaration of the array m.
The Symbol Table is telling us the address that function foo starts at, and the first source code line
that generated any code. The Link map also shows the segment for the function foo starting at 0077H
in CODE memory:
---- ---- ------ ---------- ------------
- 34 -
LX51 4. Map file
* * * * * * * CODE M E M O R Y * * * * * * *
4.7.3 Locating a module’s PDATA variables

Because all PDATA segments from all modules are grouped into a single segment, it is not clear from
the Link map where the PDATA variables in a specific module are located. The Symbol Table helps us
to identify the variable locations easily.
First, the start and end address of the PDATA segment must be known. This is easily determined from
looking at the Link map. In this example the PDATA segment starts at 0000H and ends at 0002H. If we
look at the symbols for the module we are interested in, in the Symbol Table, we can clearly see which
symbols are located in PDATA/XDATA memory space by the “X” in front of their address:
------- MODULE main

C:008BH PUBLIC main
C:0077H PUBLIC foo
C:0069H PUBLIC y
X:0003H PUBLIC xa
X:0002H PUBLIC pc
X:0001H PUBLIC pb
X:0000H PUBLIC pa
D:0031H PUBLIC p
------- ENDMOD main
All the symbols located from X:0000H to X:0002H are PDATA variables declared in the module main.
Any other symbols located in XDATA, not inside the XDATA segment are XDATA variables.
Note: This same method may be used to find the location and order of variables in any segment.
4.7.4 Cross reference file

The Cross reference file is an additional file generated by the Linker, and provides additional
information on the symbols in the absolute object file.
The Cross Reference file has the extension .xrf and is a plain ASCII text file.
The following Linker directives control the generation of the Cross Reference file.
Directive Cross reference file directive description
IXREF Generate a Cross Reference file
NOIXREF Do not generate a Cross Reference file
The Cross Reference file contains one table. Each line of the table contains one symbol.
The following table describes the information on each line:
Information Cross reference file information description
Name Symbol name.
Usage Memory space of the symbol. NUMBER can correspond to any memory space
- 35 - F
4. Map file LX51
Information Cross reference file information description

Module Names A module name in [ and ] where the symbol is declared. Then a optional list of
module names which use the symbol
The Cross Reference file contains one table, which looks like the following example:
INTER-MODULE CROSS-REFERENCE LISTING

------------------------------------
NAME. . . . . . . . USAGE MODULE NAMES

----------------------------------------
?C_INITSEGSTART . . CODE [_C_INITD]: C1S
?C_START1 . . . . . CODE [C1S]: MAIN
bank2 . . . . . . . CODE [MAIN3]:
bar . . . . . . . . CODE [MAIN2]: MAIN,
foo . . . . . . . . CODE [MAIN]: MAIN3
funcptr . . . . . . DATA [MAIN]:
IDATALEN . . . . . NUMBER [_C_IDATALEN]: C1S
main . . . . . . . CODE [MAIN]: C1S,
p . . . . . . . . . DATA [MAIN]:
p1 . . . . . . . . XDATA [MAIN2]:
pa . . . . . . . . XDATA [MAIN]:
pb . . . . . . . . XDATA [MAIN]:
pc . . . . . . . . XDATA [MAIN]:
x . . . . . . . . . DATA [MAIN]:
x1 . . . . . . . . XDATA [MAIN2]:
xa . . . . . . . . XDATA [MAIN]:
y . . . . . . . . . CODE [MAIN]:
_crunch . . . . . . CODE [MAIN3]:
_INITP2? . . . . . NUMBER [_C_IDATALEN]: C1S
_STACK . . . . . . IDATA [MAIN3]: C1S
For example the symbol bar (which is a function) is declared and possibly used in the module MAIN2
and used in the module MAIN. This is indicative of an inter-Module function call.
If Code Banking is being used then CODE symbols not located in the Common Area will be indicated
by the word “BANK” at the start of the line in the Cross Reference file.
- 36 -
LX51 5. Segment relocation
5. Segment relocation
There are two kinds of segments, relocatable and absolute.
• Absolute segments must be located at a location determined by the compiler or assembler.
• Relocatable segments are located automatically by the Linker.
The Linker provides a set of directives that enable the user to direct how the Linker should locate
relocatable segments. These directives provide different types of constraints on where the Linker may
locate the segments.
The following table shows the types of Relocation constraints possible:
Restrictiveness Constraint type Directives
Most restrictive Absolute CODE, DATA, XDATA, BIT, IDATA
Ordering CODE, DATA, XDATA, BIT, IDATA, PRECEDE, STACK
Alignment PAGE
Least Restrictive Memory CODE, DATA, XDATA, BIT, IDATA, PDATA, STARTCODE
Note: Some directives can provide more than one constraint.
It is also possible to instruct the Linker to locate absolute segments at an offset using the
ABSOLUTECODEOFFS and MOVEABSCODE directives.
This chapter will discuss the process the Linker goes through to locate segments. It will then highlight
the various methods of relocating segments and how to double-check that the memory map for a
project is right.
5.1 Segment location process

The Linker performs the following steps when locating segments:
• The register banks are reserved.
• All absolute segments are located, applying an offset or new location if specified.
• All relocatable segments whose absolute locations have been specified are located.
• All relocatable segments whose relocation order is specified are located (excluding the STACK
directive). If a relocation order is specified with both DATA and PRECEDE directives then the
PRECEDE directive is handled first.
• All remaining relocatable segments are located, starting with the largest segment and working
down to the smallest segment.
• All relocatable segments whose relocation order is specified using the STACK directive are
located.
• The stack is located.
For the last two steps the Linker locates the segments according to alignment and memory restrictions.
For example if XDATA memory starts at 1000H and a segment to be located needs to be page-
aligned, then the segment will be located at the first free page-aligned location that can accommodate
the segment, above 1000H.
Memory restrictions are not taken into account when locating absolute segments or relocatable
segments whose locations have been absolutely specified.
- 37 - F
5. Segment relocation LX51
5.2 Absolute relocation

Absolute relocation is used when a relocatable segment must be located at a specific address. This is
achieved by using the relevant directive for the segment type and specifying the address for the
segment.
For example:
CODE(?PR?foo?MAIN(0x300))
will locate the segment ?PR?foo?MAIN at location 300H in CODE memory.
The Link map in the map file will look like the following:
---- ---- ------ ---------- ------------
IDATA 000FH 0001H * * STACK * * _STACK
* * * * * * * CODE M E M O R Y * * * * * * *
CODE 00A1H 0005H UNIT _C_INITD?CD
00A6H 025AH *** GAP ***
CODE 0300H 002DH UNIT ?PR?foo?MAIN
Notice that the segment is located at 300H, leaving a gap in the CODE space.
It is possible to absolutely locate more than one segment at a time.
For example:
XDATA(?XD?SIFT(0x4000),?XD?BRCH(0x5000))
will locate the segment ?XD?SIFT at 4000H and the segment ?XD?BRCH at 5000H.
This method is useful for locating functions at specific locations, perhaps so they are physically stored
in a particular memory device that could be replaced or erased in an upgrade.
It is also useful for locating variables at specific locations, however the at keyword or using pointers is
usually more preferable as it makes it clearer in the code what is going on.
Note: It is not possible to relocate the PDATA segment as it must always fit into a single page starting at
the base address of PDATA – specified using the PDATA directive.
For a complete description of the CODE, DATA, IDATA, BIT and XDATA directives please refer to the
directive reference in Appendix A.
- 38 -
5.3 Ordering relocation

Segment ordering should only be used when absolutely necessary as it can affect the Linker’s ability to
optimize the memory usage. Because it effectively overrides locating the largest segments first, using
segment ordering can easily result in fragmentation of the memory space.
There are two ways to specify segment ordering which are described in turn.
5.3.1 General Memory space segment ordering

The order of segments to be located first in a specific memory area may be specified using the DATA,
BIT, IDATA, CODE and XDATA directives.
For example:
XDATA(?XD?SIFT,.?XD?BRCH)
will resulting the Linker locating the segment ?XD?SIFT first followed by ?XD?BRCH. Bear in mind that
these segments will only be located after all absolute segments and relocatable segments with
absolute addresses have been located.
The result will be that ?XD?SIFT will be located in the lowest available memory location, followed by
?XD?BRCH in the next lowest available memory location. This means that the segments may not
appear consecutively in memory.
5.3.2 Internal RAM segment ordering

The PRECEDE directive allows a segment order to be specified, but only for the internal RAM.
Segments are located after the register banks and any segments that are absolutely located. For
example:
PRECEDE(?DT?FOO,?DT?BAR)
will result in the segment ?DT?FOO being located before ?DT?BAR, which will be located before all
other relocatable DATA/IDATA segments.
The DATA directive may also be used to achieve the same result as the PRECEDE directive. If both
directives are used then the segments specified using the PRECEDE directive are located first followed
by the segments specified using the DATA directive.
The STACK directive allows a segment order to be specified for segments that are to be located in
internal RAM after all other segments in internal RAM have been located, but before the stack is
located. For example:
STACK(?ID?SIFT)
Will result in the Linker locating all relocatable segments, followed by the ?ID?SIFT segment, followed
by the stack. The Link map will look something like the following:
---- ---- ------ ---------- ------------
DATA 0008H 0004H UNIT ?DT?MAIN
DATA 000CH 0001H UNIT ?DT?MAIN2
IDATA 000DH 0001H UNIT ?ID?MAIN
IDATA 000EH 0001H UNIT ?ID?SIFT
IDATA 000FH 0001H * * STACK * * _STACK
Note: The ?ID?SIFT segment is located just below the base of the stack.
- 39 - F
5.4 Alignment relocation

Alignment relocation should only be used when absolutely necessary as it can affect the Linker’s ability
to optimize the memory usage. Using alignment relocation can easily result in fragmentation of the
memory space.
There are two ways to access XDATA memory with an 8051 microcontroller: the 16-bit addressing
mode via the Data Pointer, or the 8-bit addressing mode via a register.
16-bit addressing provides access to the whole 64k of RAM. 8-bit addressing on the other hand
provides access to a single 256-byte page of RAM. Each 256-byte page is page-aligned – each page
starts on a 256-byte boundary. 0000H, 0100H, 0200H, etc are all page boundaries.
It is possible to specify specific XDATA segments that must be page-aligned. This is achieved using
the PAGE directive. Each segment specified is then aligned at the lowest available page boundary. For
example:
PAGE(?XD?MAIN)
will page-align the segment ?XD?MAIN. The Link map may look something like the following:

---- ---- ------ ---------- ------------
XDATA 0001H 0004H INPAGE ?C_XSTACK
0005H 00FBH *** GAP ***
XDATA 0100H 0001H PAGE ?XD?MAIN
Note: The ?XD?MAIN segment has been located at 100H, leaving a gap in the XDATA memory space.
- 40 -
5.5 Memory relocation

Memory relocation is specification of the start address or base address of a particular memory space,
so that no segments are located below that address. Segments that are absolutely located are not
affected by the start address.
For example: XDATA(0x1000)specifies a start address of 1000H for XDATA segments.
The Link map generated will look something like the following:
---- ---- ------ ---------- ------------
IDATA 000EH 0001H * * STACK * * _STACK
0000H 1000H *** GAP ***
XDATA 1000H 0001H UNIT ?XD?SIFT
XDATA 1006H 0001H UNIT ?XD?MAIN
Note: There is a gap 1000H bytes in size.
XDATA(0x1000,?XD?MAIN(0x100)) specifies a start address of 1000H and locates the segment ?

XD?MAIN at 100H.
The following Link map shows how the Linker handled this directive:
---- ---- ------ ---------- ------------
0000H 0100H *** GAP ***
0101H 0EFFH *** GAP ***
The ?XD?MAIN segment was located at 100H, and all the other relocatable segments (which were not
absolutely located) were located starting at 1000H.
Note: The XDATA directive affects PDATA variables as well. However if the PDATA directive is used to
specify a start address for the PDATA memory space then the PDATA segment is located starting at that
address.
- 41 - F
For example: XDATA(0x1000) PDATA(0x2000)

Results in all relocatable XDATA segments being located starting at 1000H and the PDATA segment
being located starting at 2000H.
This results in further fragmentation of the XDATA memory space.
The following Link map shows the result:

---- ---- ------ ---------- ------------
0000H 1000H *** GAP ***
1003H 0FFDH *** GAP ***
Note: The STARTCODE directive allows the start address for the CODE memory space to be specified,
duplicating that functionality of the CODE directive. However it cannot be used to locate segments or
specify segment ordering.
5.6 Absolute segment relocation

There are two directives that allow absolute segments to be relocated: ABSOLUTECODEOFFS and
MOVEABSCODE.
• ABSOLUTECODEOFFS affects all absolute code segments.
• MOVEABSCODE affects individual segments.
ABSOLUTECODEOFFS applies an offset to the location of all absolute CODE segments. For example if
an absolute CODE segment is located at 1000H, then by applying an offset of 10H, the segment will
actually be located at 1010H.
This directive is most useful when building projects where all CODE segments must reside above a
specific address, for example a bootloader.
MOVEABSCODE allows a specific absolute CODE segment to be moved from one address to another.
For example if a segment is located at 1000H then using:
MOVEABSCODE(1000H(1010H))
The segment will be relocated at 1010H.
The MOVEABSCODE directive is most useful when a set of absolute CODE segments must be relocated
without affecting other absolute CODE segments, for example when relocating all the interrupt vectors
to take into account a mapping between physical and logical addresses.
- 42 -
LX51 6. Overlaying memory
6. Overlaying memory
6.1 What is overlaying?

Memory Overlaying is a process used by the Linker to reduce the amount of RAM required by an
application by reusing memory locations for more than one variable.
Look at the following simplified example code:
void main(void) {
foo();
bar();
}
void foo(void) {
char a[2] = {0, 1};
a[1]++;
}
void bar(void) {
char b[3] = {2, 3, 4};
b[2]--;
}
The automatic variables a and b require some memory to be reserved for them. In this case a total of 2
+ 3 = 5 bytes would be required to store both a and b. However, notice that the variable a is never used
at the same time as the variable b. Also notice that the variable b is never used at the same time as the
variable a. Therefore why not store both arrays in the same memory locations, overlaying them? This
would require only three bytes – the size of the largest variable, saving two precious bytes of RAM.
Now look at another simplified example:
void main(void) {
foo();
}
void foo(void) {
char a[2] = {0, 1};
bar();
a[1]++;
}
void bar(void) {
char b[3] = {2, 3, 4};
b[2]--;
}
In this example the function bar is called from the function foo. Therefore while bar is executing, the
variable a is still required and cannot be corrupted in any way. This means that the variables a and b
cannot be overlaid, otherwise initializing or modifying variable b will corrupt variable a.
This means that in order for the Linker to determine which automatic variables are suitable for
overlaying with each other, the Linker must determine the “call tree” of the application.
The “call tree” is a representation of which functions call which functions. For example:
In this diagram, the function main calls the functions foo and bar.
- 43 - F
6. Overlaying memory LX51
The function bar calls more functions, one of

main() which is the function baz.
foo() bar()
baz() Note: A “call reference” between two functions
means that one function calls the other. For
example there is a call reference between main and bar in the above diagram.
Once the Linker determines the call tree it can work out if a function’s automatic variables may be
overlaid with the automatic variables of other functions. For example from the diagram above the
Linker can work out the following rules:
1. Variables in foo and bar can be overlaid
2. Variables in foo and baz can be overlaid
3. Variables in main and foo cannot be overlaid
4. Variables in main and bar cannot be overlaid
5. Variables in bar and baz cannot be overlaid
Because variables in bar and baz cannot be overlaid, variables in foo can either be overlaid with
variables in bar or baz, but not both. The Linker then has to work out which one will produce the
optimum RAM usage.
Note: Not all automatic variables are overlaid. There are a number of reasons for this:
1. There may not be any other automatic variables to overlay with
2. Overlaying particular automatic variables may not generate the optimum RAM usage
3. The automatic variables are located entirely in registers
6.2 Directives
The following table summarizes the directives involved in overlaying variables.
Overlay directive Description
NOFCTPTRMANAG (NOFPM) Function pointers will not be automatically managed for the overlay
process.
NOOVERLAY (NOOL) Do not overlay automatic variables.
OVERLAY (OL) Overlays automatic variables if possible and controls overlaying.
SEGMENTOVERLAY (SO) Manual overlay of specified segments
A more detailed description of these directives may be found in Appendix A.
The NOFCTPTRMANAG and OVERLAY directives are discussed in section Function Pointers.
6.3 Map file

The map file is discussed in detail in Chapter 5, however here sections specific to memory overlaying
are presented.
6.3.1 Link map

The following is an example Link map generated by the first example code in this Chapter.
LINK MAP OF MODULE: C:\TEMP\FIXUPTEST\FIXUPTEST.AOF (MAIN)
- 44 -
---- ---- ------ ---------- ------------
DATA 0008H 0003H OVERLAID UNIT _DGROUP00_
DATA 000BH 0001H UNIT ?DT?MAIN
IDATA 000CH 0001H * * STACK * * _STACK
* * * * * * * CODE M E M O R Y * * * * * * *
CODE 0004H 016BH UNIT ?PR?LIB51
CODE 016FH 0072H UNIT ?PR?C51_STARTUP?
CODE 01E1H 0005H UNIT ?STR?MAIN
CODE 01E6H 0017H UNIT ?PR?foo?MAIN
CODE 01FDH 0017H UNIT ?PR?bar?MAIN
The overlaid variables are located in a segment with a special name _DGROUP00_. The name
indicates it is group 00 of overlaid variables in DATA memory. Notice that the size of the group is three
bytes – the size of the largest overlaid variable.
The Relocation name is “OVERLAID UNIT” and not only UNIT
If we look at the symbol table for the variables a and b we see the following:
VALUE TYPE NAME
----- ---- ----
D:0008H SYMBOL a
D:0008H SYMBOL b
Both variables are located at the same address, 8H in DATA memory, which corresponds to the
_DGROUP00_ segment.
- 45 - F
6.3.2 Reference map

The following is the Reference map in the map file for the same example:
REFERENCE MAP OF MODULE: C:\TEMP\FIXUPTEST\FIXUPTEST.AOF (MAIN)
SEGMENT BI_GROUP DT_GROUP XD_GROUP

+--> CALLED SEGMENT START LENGTH START LENGTH START LENGTH
---------------------------------------------------------------------------------
?PR?main?MAIN --------------- --------------- ---------------

+--> ?PR?foo?MAIN
+--> ?PR?bar?MAIN
?PR?foo?MAIN --------------- 0008H 0002H ---------------
?PR?bar?MAIN --------------- 0008H 0003H ---------------

The Reference map is a representation of the Call Tree.
There are two main differences in the way the information is represented:
• Segment names are used rather than just the function names
• The Call Tree is sliced up into groups of “function – called functions” for convenient displaying.
Each segment has the segments it calls listed underneath. Then those segments are listed separately,
again with the segments they call listed underneath them.
So in the example above it can be seen that the function main calls the functions foo and bar,
however the functions foo and bar do not call any other functions.
In the Reference map each segment is listed once, with the segments it calls listed immediately below.
On the segment line are three columns: BI_GROUP, DT_GROUP and XD_GROUP. These columns
list the start and end addresses of overlaid variables belonging to that segment, for bit-addressable,
DATA and XDATA memory spaces respectively.
Therefore in the example above, the segment ?PR?foo?MAIN (which corresponds to the function foo)
has overlaid variables in DATA memory starting at location 8H, two bytes in size. That matches up
exactly with the information in the Link map and Symbol Table.
Therefore the Reference map may be used to easily determine which function’s variables have been
overlaid with the variables of a particular function.
It can be easy to become confused if - when using a debugger - the memory locations use by a
function mysteriously become “corrupted” somewhere in the application. This is variable overlaying in
operation, and by examining the Reference map it is easy to work out where those locations are being
reused and confirm that no corruption is taking place.
- 46 -
6.4 Function pointers
6.4.1 Determining the call tree

The use of function pointers presents a problem when overlaying memory. It is not possible for the
Linker to determine which function is actually called when an indirect function call is made, so the Call
Tree cannot be determined.
Fortunately it is possible for the Linker to determine if a particular function is called via a function
pointer somewhere in the application:
• The Linker builds up a table of all the functions that are called via indirect function calls
somewhere in the application.
• When an indirect function call is encountered, the Linker treats that call as a call to every single
function in the table, for the purposes of overlaying.
Here’s an example: Let's suppose the functions foo, bar and baz are all called indirectly somewhere
in the application. Let's also suppose that the functions apple and orange each make one indirect
function call to the function baz.
The following diagrams are sections of the resultant Call Tree the Linker generates:
apple()
foo() bar() baz()
orange()
foo() bar() baz()
So, this is good in that Memory Overlaying still works when function pointers are used, however the
downside is that if a large number of function pointers are used, then a sizeable section of the
application will not be able to overlay variables and therefore use more RAM.
If RAM usage is critical and solving the overlaying problem is the only solution then the directive
NOFCTPTRMANAG may be used. This has the effect of ignoring indirect function calls when determining
the Call Tree. The result is that variables in many functions may now be overlaid, however because the
Call Tree is now incorrect, there is the possibility that variables may be corrupted.
The only solution to this is to manually fix the Call Tree using the OVERLAY directive.
6.4.2 Fixing the call tree

Let's take the apple function example.
The function apple only really calls the function bar indirectly. However because the functions foo
and bar are called indirectly elsewhere in the application the Linker determines the following Call Tree:
apple()
foo() bar() baz()
Lets assume that the function apple does not call foo or bar directly either.
Therefore the variables in apple, foo and bar could be overlaid, but because of the Linker’s
conservative approach to overlaying with function pointers they are not.
- 47 - F
There are two different ways to fix the Call Tree:

1. Using NOFCTPTRMANAG: Using NOFCTPTRMANAG results in no call reference between apple
and foo, apple and bar and apple and baz. This leads to the dangerous situation where the
variables in apple and baz could be overlaid, resulting in variable corruption. Therefore a call
reference needs to be created between apple and baz. This can be achieved with the use of
the OVERLAY directive as follows:
OVERLAY(?PR?apple?MAIN ! ?PR?baz?MAIN)
2. Not using NOFCTPTRMANAG: The call reference between apple and foo and apple and bar
can be removed using the OVERLAY directive, leaving just the call reference between apple
and baz. This can be achieve with the following directive usage:
OVERLAY(?PR?apple?MAIN ~ (?PR?foo?MAIN,?PR?bar?MAIN))
If there are a large number of function pointers in the application and only a small amount of RAM
needs to be saved, then the second method may be the better one, as it only affects one specific part
of the Call Tree, allowing call references to be gradually removed until enough RAM is saved.
6.4.3 Overlaying hints and tips

There are several things that can be taken into considerations when optimizing an application to get the
most out of variable overlaying.
• The Linker cannot overlay static variables, so wherever possible variables should be made
automatic and passed to functions as parameters if necessary. This will allow more variables to
be overlaid, as well as the very beneficial side effect that more variables will be located entirely
in registers, generating smaller, faster code.
• However, large automatic variables stored in DATA memory should be avoided. For example if
functions foo and bar have variables that are overlaid and the function bar contains a 20 byte
array, then the overlaid group for those two functions will be 20 bytes in size. Large variables are
better stored in PDATA or XDATA memory.
The compiler allows automatic variables to be declared using a memory qualifier, however be
aware that XDATA variables may only be overlaid with other XDATA variables.
• If a function contains a variable that is being overlaid and you do not want it to be overlaid, then
rather than removing the whole function from the overlaying process, simply declare that single
variable as static.
• Avoid recursion in an application if at all possible. Using recursion reduces the number of
functions that may be overlaid with each other. It may be a more effective solution to duplicate
one or two functions or restructure the application so recursion is not required.
- 48 -
LX51 7. Code banking
7. Code banking
An 8051 has a limit of 64Kb Code memory. Often an application requires more than 64Kb, for example
if large constant look-up tables are required.
The Linker includes a feature called Code Banking (also referred to as Bank Switching) that allows the
amount of Code memory to be increased up to 4Mb.
How is this achieved?
n
This diagram shows the memory
… arrangement:
2 • The address space from b to FFFFH
1 is overlaid with Code Banks.
FFFF
0 Code Banks • At any one time a single Code bank
H is selected and therefore available at
addresses b to FFFFH.
For example, if there are 4 Code Banks and
Bank 1 was selected, banks 0, 2 and 3
would not be accessible.
Therefore at any point in time the 8051 can
b only “see” 64Kb of the Code memory.
Common
0000H
Area
7.1 Code bank mechanism
7.1.1 Common area

If a function in a particular Code Bank calls a function in another Code Bank then the Linker
automatically inserts the necessary code to switch the current Bank to the one containing the function
being called. The Linker also automatically inserts the necessary code to switch back to the original
Code Bank upon return from the function. The sections of code used to perform this are called Bridges.
This raises an important question. What if the Bridges are located in a Code bank as well? If a bridge is
needed and the Code bank it is in is not selected, how is the Bank switch performed, because the
bridge is not accessible.
The bottom part of memory is called the Common Area, and – as can be seen in the diagram – it is
always accessible regardless of which Code Bank is currently selected. Code such as the Bridges
must be located in the Common Area. The following must be located in the Common Area:
• Reset Vector: Upon reset any Code Bank may be selected and there is no opportunity to select
the Code Bank containing the Reset Vector.
• Interrupt Vectors: When an interrupt occurs any Code Bank may be selected. The interrupt
vector address is loaded in hardware and there is no opportunity to select a code bank.
• Library Code: The compiler and Linker make use of library code throughout applications. Library
code performs such things as floating point mathematics, run time library functions, initialization
code, etc. Because only one copy of the Library code can be present, it must always be
available for execution.
• Constant Code: Constant Code must be placed in the Common Area, as the Linker does not
generate Bridges when accesses are made. However, Constant Code may be placed in a Code
Bank if it is ensured that when an attempt is made to access the data, the Code Bank containing
the data is selected. This is easily achieved by writing functions to read the data and locating
those functions in the same Code Bank as the data.
- 49 - F
7. Code banking LX51
7.1.2 Bank switching mechanism

This section describes what happens if a function in a Code bank calls a function in another Code
bank.
The calling function is referred to as the “caller”.
The function being called is referred to as the “callee”.
The following steps are specific to the function being called:
1. At the point where the callee is called, rather than the callee being called, the bridge relating to
the callee is called instead.
2. The register DPTR is set to the address of the callee. This address is a 16-bit address and is
the address inside the code bank.
3. The register B is set to the code bank number that contains the callee.
The following steps are generic and used for every inter-bank function call:
1. The return address (where execution must return to once the callee has completed execution) is
popped off the system stack and pushed onto the external stack. Note that when using
BANKMODE(PLM) the return address is kept on the system stack.
2. The current code bank number is pushed onto the external stack. Note that when using
BANKMODE(PLM) the current code bank number is pushed onto the system stack.
3. The symbol ?B_CURRENTBANK is assigned the new code bank number (stored in B).
4. The bank switch macro is executed to actually perform the bank switch.
5. The address of the "banked call return routine" is pushed onto the system stack.
6. DPTR (containing the address of the callee) is pushed onto the system stack.
7. RET is executed causing a jump in execution to the address stored on top of the system stack
which is the address of the callee.
When the callee finishes execution a RET instruction is executed which results in execution jumping to
the start address of the generic "banked call return routine", as the address of the routine is the top
value on the stack.
"Banked call return routine" (which is generic for every inter-bank function call return):
1. The original code bank is popped off the external stack and assigned to the symbol ?
B_CURRENTBANK. Note that when using BANKMODE(PLM) the original code bank is popped off
the system stack.
2. The original return address (where execution must return to in order to continue execution of the
caller) is popped off the external stack and pushed onto the system stack. Note that when using
BANKMODE(PLM) the return address is popped off the system stack.
3. The bank switch macro is executed to perform the bank switch to the original code bank
containing the caller.
4. RET is executed causing a jump to the original return address, as it is the top address stored on
the system stack.
The segment ?BANK?SWITCH contains the "banked call return routine" and all the bridges.
- 50 -
7.2 Code bank configuration
7.2.1 Code bank directives

It is suggested that Ride7 is used to create projects that involve code banks as Ride7 can automatically
generate the appropriate directives to ensure that code banks are correctly configured.
Code Bank Directive Description
BANK (BA) Specifies that a module should be located in a specific code bank
BANKAREA (BANKAREA) Specifies the start and end address range for code banks.
BANKMAX (BANKMAX) Specifies the upper boundary of a code bank.
BANKMIN (BANKMIN) Specifies the lower boundary of a code bank.
BANKMODE (BM) Selects code banking mode.
NOBRIDGE (NOBR) Disables generation of bridges
7.2.2 Bank switching macro

The macro is a piece of code that actually performs the bank switch from one code bank to another.
The macro may contain any code, however it must perform the following task:
Set up or configure the hardware so that the code bank in ?B_CURRENTBANK is selected.
There are two main ways to select a Code Bank:
• Using part of Port P1 to generate the additional upper address lines or chip select signals.
• Using an external memory-mapped latch to latch the additional upper address lines or chip
select signals.
Generating additional address lines results in the following physical memory map (with Code banks
E000H in size):
2FFFF
H 2
Code Bank 2
22000H
Common
20000 Area
H 1
Code Bank 1
12000H
Common
10000H Area
0
Code Bank 0
02000H
Common
Area
- 51 - F
As can be seen in the diagram, the Common Area is duplicated in every 64K block of memory.
When this arrangement is used, selecting a Code Bank can be thought of as selecting a particular 64K
“window” which the microcontroller can access. In each 64K “window” there must be a copy of the
Common Area so the code and data contained in it is always accessible.
This raises the important point that the Common Area must be as small as possible in order to reduce
the amount of memory that is wasted overall through duplication of the Common Area.
• Generating additional address lines is more efficient usage for precious port pins,
• Generating chip select signals directly removes the need for additional decoding hardware.
However chip select signals are only really useful if more than one memory device is used.
In either case, the macro allows complete flexibility and customization as to how the bank switching is
performed.
By default the macro is:
mov A,?B_CURRENTBANK
anl P1,#0f8h
orl P1,A
The default macro sets pins P1.0, P1.1 and P1.2 to indicate the current code bank, acting as additional
upper address lines. For example:
P1.7 P1.0
xxxxx000 - selects code bank 0
where (x = don’t care)

Obviously the macro would have to be changed if more than eight code banks are required.
Ride7 allows the macro to be easily modified in the Code Banking options.
7.2.3 Assembly file

When Code Banking is used the assembly file L51_BANK.A51 must be linked in with the project.
A copy of the file may be found inside the LIB folder of the Ride7 installation.
Note: The L51_BANK.A51 file should never be edited if Ride7 is being used. Only edit the file if you are
using the command line tools.
Also note that when using Ride7 a copy of the file is automatically added to the project when Code
Banking is selected.
- 52 -
7.3 Map file
7.3.1 Link map

The following is an example Link map for a Code Banking application, as show in the Linker map file.
For more information on the map file please refer to Chapter 5.
LINK MAP OF MODULE: C:\TEMP\BANKTEST\BANKTEST.AOF (L51_BANK)

---- ---- ------ ---------- ------------
DATA 0008H 0001H UNIT ?DT?BANK?SWITCH
DATA 0009H 0001H UNIT ?DT?BANK2
DATA 000AH 0001H UNIT ?C_SPX
IDATA 000BH 0001H * * STACK * * _STACK
PDATA 0000H 0001H INPAGE ?C_XSTACK
* * * * * * * CODE M E M O R Y * * * * * * *
CODE 0003H 0056H INBLOCK ?BANK?SWITCH
CODE 0059H 000FH UNIT ?PR?C51_STARTUP?
* * * B A N K N U M B E R 1 * * *
* * * * * * * CODE M E M O R Y * * * * * * *
CODE 2000H 0004H UNIT ?PR?bank1func?BANK1
* * * B A N K N U M B E R 2 * * *
* * * * * * * CODE M E M O R Y * * * * * * *
CODE 2000H 0003H UNIT ?PR?bank2func?BANK2
Code Memory is divided up into three separate sections; the second one under the heading “Bank
Number 1” and the third under “Bank Number 2”.
The first Code Memory section is the Common Area. The other two sections are code banks, and it
can be seen that the Code Banks in this example start at location 2000H.
- 53 - F
7.3.2 Bridges
The bridges created by the Linker are listed in the map file. The following is an example that matches
the Link map shown in this section:
BRIDGES CREATED :
_bank1func (004AH) ?PR?bank1func?BANK1[1]
_bank2func (0054H) ?PR?bank2func?BANK2[2]
Each line contains four pieces of information:
• The first item is the bridge name, and also the symbol used to identify the start address of the
bridge.
• The second item is the address of the bridge. Note that by cross-referencing these locations
with the Link map it can be seen that both bridges are contained in the segment ?BANK?
SWITCH.
• The third item is the segment name containing the function that the bridge calls.
• The fourth and final item is the code bank number that the segment is located in.
7.4 Locating functions and constants

Segments are located in specific Code Banks on a per-module basis. I.e. all code segments in a
module must be located in the same Code Bank. Therefore it is not possible to locate individual
segments in specific Code Banks.
7.4.1 Locating functions

All functions for a specific Code Bank must be declared in the same source file or set of source files.
For example they could all be declared in FOO.C or FOO.C and BAR.C. The BANK directive would then
be used to specify that the module FOO or the modules FOO and BAR are to be located in Code Bank 3:
BANK3{FOO} BANK3{BAR}
7.4.2 Locating constants

Constants are easy to locate in Code Banks, however because there are no Bridges created for
accessing constants in Code Banks an “access function” is required.
For each Code Bank that contains constants, there must be one or more “access functions” that must
be called to retrieve the values of the constants or information based on the constants. The “access
function” must be the only way the constant data is accessed throughout the entire application, and
must only access constant data in the same Code Bank as it resides.
The reason for this is because when the “access function” is called the Code Bank will be switched to
the one containing the constant data. The constant data may then be accessed.
Here is an example:
const unsigned char code seventimestable[] = {0, 7, 14, 21, 28, 35, 42};
unsigned char get_seventimestable(unsigned char index)
{
return seventimestable[index];
}
The resultant Link map will look something like:
* * * B A N K N U M B E R 2 * * *
* * * * * * * CODE M E M O R Y * * * * * * *
CODE 2000H 0007H UNIT ?PR?BANK2
CODE 2007H 0009H UNIT ?PR?_get_seventimestable?BANK2
- 54 -
Note: The function and the constant code are located in the same Code Bank.
Large Look-up tables may not fit into a single Code Bank, however, using “access functions” it is easy
to split the table up into sections.
For example, a look-up table 10000H in size, fitting into Code Banks 8100H in size:
Bank 1:
const unsigned char code table_b1[0x8000] = {0, 1, 2};
unsigned char get_table_value(unsigned int index)

{
if (index >= 0x8000) return get_table_b2_value(index - 0x8000);
return table_b1[index];
}
Bank 2:
const unsigned char code table_b2[0x8000] = {3, 4, 5};
unsigned char get_table_b2_value(unsigned int index)

{
return table_b2[index];
}
So to access the table a call to get_table_value is made, passing an index in the range 0x0000 –
0xFFFF.
Note: During assembly, the Linker cannot determine that bridges should not be generated for constants
in Code memory, and generates bridges for all public symbols in Code memory. This results in wasted
memory. The NOBRIDGE directive may be used to avoid this. Refer to Appendix A for a full description of
the directive.
7.5 Code banking hints and tips

Every time a bank switch must be performed precious processing cycles are taken away from the
application’s task. Therefore for optimum performance the number of bank switches required by an
application to execute must be as low as possible.
This can be achieved by careful location of functions and constant data. For example if an application
contains a main loop where the same set of functions are repeatedly called, then the function
containing the loop and those set of functions should be located in the same Code Bank.
The execution time of Interrupt Service Routines is usually critical. Therefore functions that are called
by an ISR should be located in the Common Area to remove the possibility that a bank switch may be
required. The same is true of any constant data that is required by an ISR.
However, for optimum memory usage the Common Area should be as small as possible. This reduces
the amount of memory that is wasted in duplicating the Common Area and could be used by functions
or data.
- 55 - F
8. Flash mode LX51
8. Flash mode
8.1 What is Flash mode?

Quite often a project requires that part of the software be stored in ROM and part be stored in Flash,
making it upgradeable at a future date. The 8051 Linker contains built-in support for such an
arrangement, called Flash mode.
An application is developed in Flash mode using the following general steps:
1. Initially the ROM is “unlocked”. Both the ROM code and the initial Flash code are developed.
Internal RAM is reserved for future changes.
2. When testing is complete the ROM is “locked” to prevent further change. The reserved memory
becomes available.
3. The ROM and Flash devices are programmed.
4. The Flash code is modified without fear that the ROM code will change.
5. The Flash devices are reprogrammed.
8.2 Directives
The following table summarizes the directives used with Flash Mode:
Flash Directive Description
FLASH (FLS) Specifies the start address of Flash memory and the object files to locate in Flash.
FLASHBANKAREA Specifies the start and end address range which Flash banks occupy.
(FLSBANKAREA)
FLASHNAME (FLN) Specifies the file to store Flash information.
NOSTATVARROM Locates the initial values of static variables in Flash rather than ROM.
(NOSTATVARROM)
REFLASH (REFLS) Specifies the file containing Flash information in locked mode.
RESERVE (RES) Reserves memory for future enhancements.
STATVARROM Locates the initial values of static variables in ROM rather than Flash.
(STATVARROM)
8.3 Using Flash mode
8.3.1 Developing ROM and Flash code

Initially both the ROM code and the Flash code must be developed. Individual modules may be located
in Flash.
On the command line the FLASH directive allows the Flash modules to be specified, along with the start
address of Flash memory. In Ride7 selection of the Use Flash mode option along with entering the
start address for Flash memory into the Start Address field and indicating which modules are locating
in Flash, achieves the same result.
The FLASHNAME directive specifies the filename of the Flash file. In Ride7 the filename may be entered
into the field to the left of the Locked Mode checkbox.
The Flash file usually has the extension .fls and is an object file that stores information about the ROM.
This file is generated in unlocked mode and is required when using the locked mode.
- 56 -
LX51 8. Flash mode
A typical Link map will look like the following (please see Chapter 5 for a complete description of the
map file and its contents):
LINK MAP OF MODULE: C:\TEMP\FIXUPTEST\FIXUPTEST.AOF (BAR)

---- ---- ------ ---------- ------------
DATA 0009H 0001H UNIT ?DT?BAR
DATA 000AH 0001H UNIT ?DT?FOO
000BH 0015H *** GAP ***
DATA 0020H 0005H BITADDRESSABLE ?Reserve?BDATA
BIT 0025H 0001H UNIT ?Reserve?BIT
DATA 0026H 0020H UNIT ?Reserve?DATA
* * * * * * * CODE M E M O R Y * * * * * * *
* * * F L A S H A R E A * * *
* * * * * * * CODE M E M O R Y * * * * * * *
CODE 8009H 0003H UNIT ?PR?bar?BAR
CODE 800CH 0003H UNIT ?PR?foo?FOO
CODE 800FH 0001H UNIT _C_INITD?CD
There are several items of note in the Link map:
• The Flash area is shown as a separate code memory area starting at 8000H, where the
segments to be located in Flash are listed.
• The segment ?FLASH?TABLE_00? Contains a symbol table that matches up function names
and symbols with addresses. Any calls to functions in Flash memory result in the address of the
function being obtained from the table. This allows the functions in Flash to change locations
while the application will still function.
• The segment _C_INITD?CD contains the initial values of the static variables in the application.
Because this segment is located in Flash at a future date the Flash may be changed to include
additional initialized static variables. The directives NOSTATVARROM and STATVARROM
control the location of this segment – either in Flash or ROM.
• The segments ?Reserve?BDATA, ?Reserve?BIT and ?Reserve?DATA are special segments
that reserve bit-addressable data memory and regular data memory for use in future updates of
the Flash code. The amount of memory to reserve of each type is controlled using the
RESERVE directive.
Two Hex files are generated:
• projectname.hex – ROM Code
• projectname.he0 – Flash Code
- 57 - F
8. Flash mode LX51
8.3.2 Locking the ROM

To lock the ROM in Ride7 select the Locked Mode option in the Linker options.
To lock the ROM on the command line the REFLASH directive is used, specifying the Flash file created
previously.
8.3.3 Updating the Flash Code

Once locked the modules located in Flash may be changed to generate a new .he0 hex file for the
Flash. The Link map in the map file will change to something like the following:
LINK MAP OF MODULE: C:\TEMP\FIXUPTEST\FIXUPTEST.AOF (BAR)

---- ---- ------ ---------- ------------
DATA 0008H 0001H # UNIT ?DT?MAIN
DATA 0009H 0001H UNIT ?DT?BAR
DATA 000AH 0001H UNIT ?DT?FOO
IDATA 000BH 0001H * * STACK * * _STACK
* * * * * * * CODE M E M O R Y * * * * * * *
CODE 0000H 0003H # ABSOLUTE
CODE 0003H 0072H # UNIT ?PR?C51_STARTUP?
CODE 0075H 0008H # UNIT ?PR?main?MAIN
* * * F L A S H A R E A * * *
* * * * * * * CODE M E M O R Y * * * * * * *
CODE 8012H 0003H UNIT ?PR?bar?BAR
CODE 8015H 0003H UNIT ?PR?foo?FOO
In the table some of the segments feature a “#” just before the Relocation type. These segments are
locked against further change.
Notice that the reserved segments have disappeared leaving free memory that may now be used.
It is also possible to add new source files to the project. The generated modules will automatically be
stored in the Flash memory.
- 58 -
LX51 9. Kernel
9. Kernel
The Kernel is a Real-Time Operating System (RTOS) that enables functions to be declared as tasks,
providing a method to write real-time multitasking systems.
The Kernel provides time slicing capabilities that have been optimized for the 8051 architecture.
Each task can be assigned a priority and when a task is running it is unaware of other tasks in the
system.
The Kernel is provided in the form of a library that is linked in with an application, generating a single
absolute object file, and therefore a single Hex file.
A header file must be included in the source code to gain access to the Kernel’s functions and
services.
9.1 Linking
The Kernel is linked in with a project by choosing Options | Project Properties, expanding the LX51
part of the tree and selecting KR-51 Kernel.
9.2 Configuration
The window allows various configuration options to be set. Ride7 generates a special object file
containing symbols whose values correspond to the settings. The object file is passed to the Linker and
the Kernel code then makes use of the symbols for configuration. This means that it is not possible to
Link a project with the Kernel using the Command Line. Instead Ride7 must be used.
9.2.1 Kernel model

The Kernel can operate in the following three models, the desired one may be selected using the
appropriate option.
Model XDATA requirement Maximum number of tasks Description

KR-Tiny - 7 For small applications
KR-Standard 256 bytes 29 For medium sized applications
KR-Huge 1 Kbytes 125 For large applications
Selection of the model depends on the applications requirements and XDATA memory available.
Each model may be used with or without debug capabilities and semaphores.
Using either option slows down execution of the Kernel and requires additional RAM, however debug
capabilities provide a more robust environment, and semaphores may be used to control access to
global variables and peripherals.
9.2.2 Time
When the option Use the automatic definitions is selected then the clock and dividers settings in the
window will be used. If it is not selected then the settings must be provided in an assembler source file
and linked in with the project.
9.2.3 Clock
Specifies the relationship between the CPU clock cycles and the Kernel tick rate. For example if the
value of 1000 is used then 1000 CPU clock cycles is equivalent to one Kernel tick.
- 59 - F
9. Kernel LX51
For a 12MHz crystal, 1000 clock cycles is 83.333us. Therefore one Kernel tick is 83.333us.
The lower the value the faster the system will run, however if the value is too low then the Kernel will
spend all its time switching tasks, and not allow any tasks to execute.
9.2.4 Dividers
Each task is associated with a group. Each group of tasks execute at a specific speed that is a division
of the Kernel ticks.
• The Group 1 divider is the number of Kernel ticks in a Group 1 tick.
• The Group 2 divider is the number of Group 1 ticks in a Group 2 tick.
• The Group 3 divider is the number of Group 2 ticks in a Group 3 tick.
For example, if a Kernel tick is 83.333us , the Group 1 divider is 10, the Group 2 divider 100 and the
Group 3 divider 1000, then:
• Group 1 tick = 10 x Kernel tick = 833.333us
• Group 2 tick = 100 x Group 1 tick = 83.333ms
• Group 3 tick = 1000 x Group 2 tick = 83.333s
Therefore if a task in Group 3 waits for 5 ticks, it is waiting for 5 x 83.333s = 416.667s, which is about 6
minutes and 57 seconds.
On the other hand, if a task in Group 1 waits for 5 ticks, it is waiting for 5 x 833.333us = 4.167ms.
Separating tasks into groups allows the Kernel and the system to perform more efficiently and removes
the need for counters to be used inside rapidly executing tasks simply to measure a relatively long
period of time.
- 60 -
LX51 10. Initialization, buffers and stacks
10. Initialization, buffers and stacks
The Linker provides various options to configure aspects of the memory usage. For example the Linker
can initialize internal RAM, allocate a specific amount of memory for printf and sprintf to operate
with, allow you to specify the size of the external stack, and initialize UART 0 to use a particular baud
rate. This chapter describes those options.
10.1 Initializing internal RAM

It is possible to specify that internal IDATA memory be initialized by making a copy of the startup.a51
file, adding it to the project and changing the options inside it (for more information please refer to the
compiler manual). However the Linker, through Ride7, provides an easy method of specifying the
amount of IDATA memory to be initialized to 0.
To set the option choose Options | Project, expand the LX51 portion of the tree and click on Startup.
Ride7 provides a field where the number of bytes to initialize (starting at location 00H) can be entered:
The value entered is passed to the Linker using the RSI directive.
Note: Initializing internal RAM is a very good idea. It improves the chances that an uninitialized pointer or
variable will point to or have the value zero, which is usually a safer value for a variable or pointer to
have.
10.2 Printf/sprintf buffer size

Both printf and sprintf require a buffer to use as scratch space when constructing a formatted
string. As a rule of thumb, this buffer must be twice as large as the largest argument plus 16 bytes. For
example if the largest argument is the floating point number 1.563e+5, then the buffer must be at least
2 x 5 + 16 = 26 bytes.
To set the option choose Options | Project, expand the LX51 portion of the tree and click on Linker.
The default buffer size is 16 bytes which is large enough for standard argument printing without
formatting. Ride7 allows the buffer size to be set to a specific value. This is required if you wish to use
printf or sprintf with large arguments.
If the value is changed from the default then Ride7 generates a special input object file containing the
public symbol SIZEBUFPRINTF. The symbol is set to the value entered for the buffer size. The object
file is linked with the other object files to enable the printf and sprintf library code to use the
symbol.
10.3 External stack size

When the Huge memory model is selected, all stack operations take place on a simulated external
stack. In addition, whenever re-entrant functions are included in a project and the compiler EXTSTK
directive is used, the simulated external stack is used for storage of the automatic variables and data.
To set the option choose Options | Project, expand the LX51 portion of the tree and click on Linker.
- 61 - F
10. Initialization, buffers and stacks LX51
The maximum size of the external stack is 256 bytes, however the size may be reduced. For example
if a device features 256 bytes of on-chip XDATA memory then 128 bytes could be used for the stack
and 128 bytes for variable storage.
Ride7 provides an easy way to set the size of the external stack, by entering the stack size into the
External stack size field.
public symbol XSTACKLEN. The symbol is set to the value entered for the stack size. The object file is
linked with the other object files to enable the external stack library code to use the symbol.
10.4 UART 0 initialization

When one of the following functions are used in a project the Linker will automatically insert into the
startup code an initialization of UART 0:
• Printf
• Scanf
• Puts
• Gets
• Getchar
• Ungetchar
• Putchar
• Getkey
The UART is initialized to use mode 1 (10-bits, variable baud rate) and use timer 1 as a baud rate
generator. Timer 1 is initialized to use mode 2 (8-bit auto reload). This is provided to save development
time. However, it is necessary to select the correct timer 1 reload value in order to generate a specific
baud rate for a specific clock frequency.
Ride7 provides a input field in the Linker options where an 8-bit reload value may be specified.
public symbol TIM1_INIT. The symbol is set to the value entered for the reload value. The object file
is linked with the other object files to enable the startup library code to use the symbol. To set the
option choose Options | Project, expand the LX51 portion of the tree and click on Startup.
Note: If it is not possible to generate the desired baud rate with an 8-bit reload value, or, if the Linker’s
initialization is not suitable for the application or microcontroller being used, then the peripherals can be
initialized as normal in the C source code, ignoring the Linker generated initialization code.
- 62 -
LX51 11. Appendix A. Directives reference
11. Appendix A. Directives reference

These tables summarize the directives present in the Linker and the categories they fall into. After the
tables each directive is described in detail.
11.1 Relocation directives summary
Directive Description
ABSOLUTECODEOFFS Offsets the address of all absolute code segments.
(ABSCODEOFFS)
BIT (BI) Specifies how relocatable bit-addressable segments should be located.
CODE (CO) Specifies how relocatable CODE segments should be located.
DATA (DT) Specifies how relocatable DATA segments should be located.
IDATA (ID) Specifies how relocatable IDATA segments should be located.
INPAGE (IP) Specifies segments that must fit into a 256-byte page.
MOVEABSCODE (MAC) Moves an absolute code segments to a new location.
PAGE (PA) Page aligns XDATA segments.
PDATA (PD) Specifies how relocatable PDATA segments should be located.
PRECEDE (PC) Specifies relocatable segments that must be located first.
STACK (ST) Specifies relocatable segments that must be located last.
STARTCODE (STCO) Specifies a start address for relocatable code segments.
XDATA (XD) Specifies how relocatable xdata segments should be located.
11.2 Memory directives summary
CODESIZE (CSIZE) Specifies the size of the CODE area.
MEMORYOFFSET (MO) Applies an offset to addresses used to access a segment.
NOFCTPTRMANAG (NOFPM) Function pointers are not automatically managed for the overlay process.
NOOVERLAY (NOOL) Do not overlay automatic variables.
OVERLAY (OL) Overlays automatic variables if possible and controls overlaying.
RAMSIZE (RS) Specifies the size of IDATA memory.
RAMSIZEINIT (RSI) Specifies the amount of IDATA to initialize.
SEGMENTOVERLAY (OS) Specifies segments for manual overlays.
-VN Instructs the Linker to assume a Von Neumann memory architecture.
XDATASIZE (XSIZE) Specifies the size of XDATA memory.
- 63 - F
11. Appendix A. Directives reference LX51
11.3 Map file directives summary
IXREF (IX) Instructs the Linker to generate a Cross-Reference file.
LINES (LI) Insert source code lines into symbol table.
MAP (MA) Include the Link map in the map file.
NOIXREF (NOIX) Instructs the Linker to not generate a Cross-Reference file.
NOLINES (NOLI) Omit source code lines from the symbol table.
NOMAP (NOMA) Omit the Link map from the map file.
NOPRINT (NOPR) Instructs the Linker to not generate a map file.
NOPUBLICS (NOPU) Omit public symbols from the symbol table.
NOSYMBOLS (NOSB) Omit symbols local to a module from the symbol table.
PRINT (PR) Instructs the Linker to generate a map file.
PUBLICS (PU) Inserts public symbols into the symbol table.
SYMBOLS (SB) Inserts symbols local to a module into the symbol table.
11.4 Object file directives summary
-C Turns on case sensitivity.
CASESENSITIVITY (CS) Turns on case sensitivity.
DEBUGLINES (DL) Includes source code line numbers in AOF file for debugging.
DEBUGPUBLICS (DP) Includes public symbols in AOF file for debugging.
DEBUGSYMBOLS (DS) Includes symbols local to modules in AOF file for debugging.
NAME (NA) Specifies the output module name.
NOCASESENSITIVITY (NOCS) Turns off case sensitivity.
NODEBUGLINES (NODL) Omit source code line numbers from the AOF file.
NODEBUGPUBLICS (NODP) Omit public symbols from the AOF file.
NODEBUGSYMBOLS (NODS) Omit symbols local to modules from the AOF file.
NODEFAULTLIBRARY (NLIB) Don’t automatically link in libraries when required.
POSTOPTI (POSTOPTI) Inserts information into the AOF file for post-linking optimization.
TO (TO) Specifies the filename of the AOF file.
- 64 -
11.5 Code banking directives summary
BANK (BA) Specifies that a module should be located in a specific code bank
BANKAREA (BANKAREA) Specifies the start and end address range for code banks.
BANKMAX (BANKMAX) Specifies the upper boundary of a code bank.
BANKMIN (BANKMIN) Specifies the lower boundary of a code bank.
BANKMODE (BM) Selects code banking mode.
NOBRIDGE (NOBR) Disables generation of Bridges
11.6 Flash directives summary
FLASH (FLS) Specifies the start address of Flash memory and the object files to locate
in Flash.
FLASHBANKAREA Specifies the start and end address range which Flash banks occupy.
(FLSBANKAREA)
FLASHNAME (FLN) Specifies the file to store Flash information.
NOSTATVARROM Locates the initial values of static variables in Flash rather than ROM.
(NOSTATVARROM)
REFLASH (REFLS) Specifies the file containing Flash information in locked mode.
RESERVE (RES) Reserves memory for future enhancements.
STATVARROM Locates the initial values of static variables in ROM rather than Flash.
(STATVARROM)
11.7 Miscellaneous directives summary
AMAKE (AM) Ignored. Included for Keil compatibility.
GLOBAL (GLB) Allows directives to be used globally on all tools without generating errors.
NOAMAKE (NOAM) Ignored. Included for Keil compatibility.
- 65 - F
11.8 ABSOLUTECODEOFFS (ABSCODEOFFS)

Syntax: ABSOLUTECODEOFFS(offset)
Description: Offsets the address of all absolute code segments by the amount of bytes specified.
For example if an absolute code segment is supposed to be located at 1000H and
ABSOLUTECODEOFFS(10H) is used then the absolute code segment will be located at
1010H.
This directive is useful when a project must be built with all code segments above a
specific non-zero address, for example a bootloader.
Examples: ABSOLUTECODEOFFS(16) Offsets all absolute code segments by 16 bytes
ABSOLUTECODEOFFS(10H) Same as above
ABSOLUTECODEOFFS(0x10) Same as above
Default: ABSOLUTECODEOFFS(0000H)
Category: Relocation
See Also: CODE, MOVEABSCODE, STARTCODE
11.9 AMAKE (AM)

Syntax: AMAKE
Description: This directive has no effect and is included only for Keil compatibility.
Examples: AMAKE
Default: AMAKE
Category: Miscellaneous
See Also: NOAMAKE
11.10 BANKAREA (BANKAREA)

Syntax: BANKAREA(startaddress,endaddress)
Description: Specifies the start and end address range over which the Code Banks occupy.
Examples: BANKAREA(8000H,FFFFH) Code Banks occupy addresses 8000H to FFFFH
BANKAREA(0x8000,0xFFFF) Same as the above example
Default: Code Banking is not used
Category: Code Banking
See Also: BANK, BANKMAX, BANKMIN
11.11 BANKMAX (BANKMAX)

Syntax: BANKMAX(number,endaddress)
Description: Specifies the upper boundary of a particular Code Bank.
Examples: BANKMAX(2,0xF000) Bank number 2 will end at 0xF000.
See Also: BANK, BANKAREA, BANKMIN
- 66 -
11.12 BANKMIN (BANKMIN)

Syntax: BANKMIN(number,startaddr)
Description: Specifies the lower boundary of a particular Code Bank
Examples: BANKMIN(2,0x8500) Bank number 2 will start at 0x8500.
See Also: BANK, BANKAREA, BANKMAX
11.13 BANKMODE (BM)

Syntax: BANKMODE(mode)
Description: Selects the mode used for Code Banking.
Examples: BANKMODE(PLM) Selects Code Banking without the use of a external stack
BANKMODE(SMA) Selects Code Banking using small Bridges
BANKMODE(LAR) Selects Code Banking using large Bridges
Default: BANKMODE(SMA)
Category: Code banking
See Also: NOBRIDGE
- 67 - F
11.14 BIT (BI)

Syntax: BIT(addr|segment[(addr)][,segment[(addr)]][…])
Description: Specifies how relocatable bit-addressable segments should be located. The directive
provides the following control over the location of these segments:
• Specifying a start address, below which no segments will be located
• Specifying an address for an individual segment
• Specifying an order for segments to be located.
If the first parameter is an address then no relocatable bit-addressable segments will be
located below that address.
If any segment names have a following address in parentheses then that segment will
be located at that address (provided no other segments are already located at that
address). The address may be below the start address specified.
The remaining segments specified are located in the order that they are specified.
If there are relocatable bit-addressable segments whose location or order of location is
not important then they may be omitted from the list of segments specified with this
directive. The start address will be applied to them however.
Examples: BIT(24H)
Locates all relocatable bit-addressable segments at least 24H bits from the start
of the bit-addressable area at 20H
BIT(0x24)
Same as the above example
BIT(36)
BIT(36,?BI?MAIN)
Same as above, however the segment ?BI?MAIN is located first
BIT(36,?BI?MAIN,?BI?MAIN2)
Same as above, however the segment ?BI?MAIN2 is located after segment ?BI?
MAIN
BIT(36,?BI?MAIN(38))
Locates all relocatable bit-addressable segments at least 36 bits from the start of
the bit-addressable area at 20H, however the segment ?BI?MAIN is located 38
bits from the start of the bit-addressable area at 20H.
BIT(26,?BI?MAIN,?BI?MAIN2(20),?BI?MAIN3)
Locates all relocatable bit-addressable segments at least 36 bits from the start of
the bit-addressable area at 20H, however the segment ?BI?MAIN2 is first
located 20 bits from the start of the bit-addressable area at 20H, then segment ?
BI?MAIN is located followed by segment ?BI?MAIN3.
Default: BIT(00H)
See Also: CODE, DATA, IDATA, PDATA, XDATA
- 68 -
11.15 -C
Syntax: -C
Description: Turns on Case Sensitivity in the Linker. ANSI C is case sensitive.
The variable FOO is not the same variable as the variable foo. However the OMF-51 file
format that is used for the object file is not case sensitive and FOO and foo will end up
referencing the same variable.
This directive ensures that the OMF-51 files are case sensitive. Therefore if your code
relies on case sensitivity you must use this directive.
This directive must appear before the list of input modules on the command line so the
Linker knows that it must parse all object files using case sensitivity.
Examples: -C
Default: The Linker is not case sensitive
Category: Object file
See Also: CASESENSITIVE, NOCASENSITIVE
11.16 CASESENSITIVE (CS)

Syntax: CASESENSITIVE
Description: Turns on Case Sensitivity in the Linker. ANSI C is case sensitive.
The variable FOO is not the same variable as the variable foo. However the OMF-51 file
format that is used for the object file is not case sensitive and FOO and foo will end up
referencing the same variable.
This directive ensures that the OMF-51 files are case sensitive. Therefore if your code
relies on case sensitivity you must use this directive.
This directive must appear before the list of input modules on the command line so the
Linker knows that it must parse all object files using case sensitivity.
Examples: CASESENSITIVE
Default: NOCASESENSITIVE (The Linker is not case sensitive)
See Also: -C, NOCASESENSITIVE
- 69 - F
11.17 CODE (CO)

Syntax: CODE(addr|segment[(addr)][,segment[(addr)]][…])
Description: Specifies how relocatable CODE segments should be located. The directive provides the
following control over the location of these segments:
• Specifying a start address, below which no relocatable segments will be located
If the first parameter is an address then no relocatable CODE segments will be located
below that address. If any segment names have a following address in parentheses then
that segment will be located at that address (provided no other segments are already
located at that address). The address may be below the start address specified. The
remaining segments specified are located in the order that they are specified.
If there are relocatable CODE segments whose location or order of location is not
important then they may be omitted from the list of segments specified with this directive.
The start address will be applied to them however.
Examples CODE(24H) Locates all relocatable CODE segments at least 24H bytes from the start of
the code area.
CODE(0x24) Same as the above example
CODE(36) Same as the above example
CODE(36,?PR?FOO?MAIN)
Same as above, however segment ?PR?FOO?MAIN is located first
CODE(36,?PR?FOO?MAIN,?PR?BAR?MAIN2)
Same as above, however segment ?PR?BAR?MAIN2 is located after segment ?PR?
FOO?MAIN
CODE(36,?PR?FOO?MAIN(38))
Locates all relocatable CODE segments at least 36 bytes from the start of the CODE
area, however: segment ?PR?FOO?MAIN is located 38 bytes from the start of the
CODE area.
CODE(26,?PR?FOO?MAIN,?PR?BAR?MAIN2(20),?PR?BAZ?MAIN3)
Locates all relocatable CODE segments at least 26 bytes from the start of the CODE
area, however: segment ?PR?BAR?MAIN2 is first located 20 bytes from the start of
the CODE area, then segment ?PR?FOO?MAIN is located followed by segment ?
PR?BAZ?MAIN3.
Default: CODE(0000H)
See Also: ABSOLUTECODEOFFS, BIT, DATA, IDATA, MOVEABSCODE, PDATA, STARTCODE, XDATA
11.18 CODESIZE (CSIZE)

Syntax: CODESIZE(size)
Description: Specifies the size of the CODE area in bytes. This is useful if there is less than 64K in
your target hardware and you wish the Linker to generate an error if an attempt is made
to locate segments in non-existent locations.
Examples: CODESIZE(32768) Specifies a code space 32768 bytes in size (32k)
CODESIZE(8000H) Same as above
CODESIZE(0x8000) Same as above
Default: CODESIZE(65536)
Category: Memory
See Also: RAMSIZE, XDATASIZE
- 70 -
11.19 DATA (DT)

Syntax: DATA(addr|segment[(addr)][,segment[(addr)]][…])
Description: Specifies how relocatable DATA segments should be located.
The directive provides the following control over the location of these segments:
If the first parameter is an address then no relocatable DATA segments will be located
below that address.
If there are relocatable DATA segments whose location or order of location is not
Examples: DATA(24H)
Locates all relocatable DATA segments at least 24H bytes from the start of the
DATA area.
DATA(0x24) Same as the above example
DATA(36) Same as the above example
DATA(36,?DT?MAIN)
Same as above, however the segment ?DT?MAIN is located first
DATA(36,?DT?MAIN,?DT?MAIN2)
Same as above, however the segment ?DT?MAIN2 is located after segment ?
DT?MAIN
DATA(36,?DT?MAIN(38))
Locates all relocatable DATA segments at least 36 bytes from the start of the
DATA area, however the segment ?DT?MAIN is located 38 bytes from the start of
the DATA area.
DATA(26,?DT?MAIN,?DT?MAIN2(20),?DT?MAIN3)
Locates all relocatable DATA segments at least 26 bytes from the start of the
DATA area, however the segment ?DT?MAIN2 is first located 20 bytes from the
start of the DATA area, then segment ?DT?MAIN is located followed by
segment ?DT?MAIN3.
Default: DATA(128)
See Also: BIT, CODE, IDATA, PDATA, XDATA
11.20 DEBUGLINES (DL)

Syntax: DEBUGLINES
Description: C source code line numbers will be included in the absolute object file generated by the
Linker. This allows C source level debugging to be performed.
Examples: DEBUGLINES
Default: DEBUGLINES
See Also: DEBUGPUBLICS, DEBUGSYMBOLS, NODEBUGLINES, NODEBUGPUBLICS,
NODEBUGSYMBOLS
- 71 - F
11.21 DEBUGPUBLICS (DP)

Syntax: DEBUGPUBLICS
Description: Public symbols will be included in the absolute object file generated by the Linker. Public
symbols are those that are used by more than one module. This allows public symbols
to be viewed and manipulated when debugging.
Examples: DEBUGPUBLICS
Default: DEBUGPUBLICS
NODEBUGSYMBOLS
11.22 DEBUGSYMBOLS (DS)

Syntax: DEBUGSYMBOLS
Description: Symbols local to a single module will be included in the absolute object file generated by
the Linker. This allows local symbols to be viewed and manipulated when debugging.
Examples: DEBUGSYMBOLS
Default: DEBUGSYMBOLS
NODEBUGSYMBOLS
11.23 FLASH (FLS)

Syntax: FLASH(startaddress,objectfile[,objectfile][…])
Description: Specifies the start address of Flash memory and the object files containing code to
locate in Flash.
When Code Banking is used with Flash mode this directive is not used. Instead use the
BANK directive to locate modules.
Examples: FLASH(8000H,FOO.OBJ)
Locates the CODE segments in FOO.OBJ in Flash starting at 8000H
FLASH(0x8000,FOO.OBJ)
FLASH(0x8000, FOO.OBJ, BAR.OBJ)
Locates the CODE segments in FOO.OBJ and BAR.OBJ in Flash starting at 8000H
Default: Flash functionality is disabled
Category: Flash
See Also: FLASHBANKAREA
- 72 -
11.24 FLASHBANKAREA (FLSBANKAREA)

Syntax: FLASHBANKAREA(startaddress,endaddress)
Description: Specifies the start and end address range over which the Flash banks occupy in CODE
memory.
This directive is used with Code banking and in place of the BANKAREA directive.
Examples: FLASHBANKAREA(8000H,FFFFH)
Flash Code Banks occupy addresses 8000H to FFFFH
FLASHBANKAREA(0x8000,0xFFFF)
Default: Flash is not used
Category: Flash
See Also: FLASH
11.25 FLASHNAME (FLN)

Syntax: FLASHNAME(filename)
Description: Specifies the filename of the file to store the Flash information.
This directive must be used when Flash is in unlocked mode.
Examples: FLASHNAME(c:\work\flsfile.fls)Stores the Flash information in file flsfile.fls
Default: Flash is not used. If Flash mode is used then the default is:
FLASHNAME(filename_based_on_project_name). For example the file will be
called FOO.FLS if the Project file is called FOO.PRJ.
Category: Flash
See Also: NAME, PRINT, REFLASH, TO
11.26 GLOBAL (GLB)

Syntax: GLOBAL(directive[,directive][,…])
Description: Directives may be passed to the Linker as parameters inside the GLOBAL directive.
The Linker uses directives that are passed this way unless they will result in the
generation of an error, in which case the Linker ignores them.
This directive is supplied primarily for the use of Ride7.
Examples: GLOBAL(DATA(?DT?MAIN(30H))) The linker locates segment ?DT?MAIN at address
30H, unless an error is generated.
Default: GLOBAL()
See Also: There are no related directives
- 73 - F
11.27 IDATA (ID)

Syntax: IDATA(addr|segment[(addr)][,segment[(addr)]][…])
Description: Specifies how relocatable IDATA segments should be located. The directive provides
the following control over the location of these segments:
If the first parameter is an address then no relocatable IDATA segments will be located
below that address.
If there are relocatable IDATA segments whose location or order of location is not
important then they may be omitted from the list of segments specified with this
directive. The start address will be applied to them however.
Examples: IDATA(24H)
Locates all relocatable IDATA segments at least 24H bytes from the start of the
IDATA area.
IDATA(0x24)
IDATA(36)
IDATA(36,?ID?MAIN)
Same as above, however the segment ?ID?MAIN is located first
IDATA(36,?ID?MAIN,?ID?MAIN2)
Same as above, but the segment ?ID?MAIN2 is located after segment ?ID?MAIN
IDATA(36,?ID?MAIN(38))
Locates all relocatable IDATA segments at least 36 bytes from the start of the
IDATA area, however the segment ?ID?MAIN is located 38 bytes from the start of
the IDATA area.
IDATA(26,?ID?MAIN,?ID?MAIN2(20),?ID?MAIN3)
Locates all relocatable IDATA segments at least 26 bytes from the start of the
IDATA area, however the segment ?ID?MAIN2 is first located 20 bytes from the
start of the IDATA area, then segment ?ID?MAIN is located followed by segment
?ID?MAIN3.
Default: IDATA(00H)
See Also: BIT, CODE, DATA, PDATA, XDATA
- 74 -
11.28 INPAGE (IP)

Syntax: INPAGE(segment[,segment][,…])
Description: Specifies that the XDATA segments must be located so that they completely fit inside a
256 byte page. The segments will be located in the lowest available location that allows
this. If a segment is larger than 256 bytes then an error will be generated. By locating a
segment using INPAGE it is guaranteed that the whole segment is accessible using 8-bit
indirect addressing (MOVX @Ri).
Examples: INPAGE(?XD?MAIN?FCT)
The XDATA segment will be located in the lowest 256 byte page where there is
enough space to fit the entire segment.
Default: Segments are not located using inpage relocation.
See Also: PAGE
11.29 IXREF (IX)

Syntax: IXREF
Description: Cross-Reference file is generated by the Linker as an aid to debugging.
Examples: IXREF
Default: IXREF
Category: Map file
See Also: NOIXREF
11.30 LINES (LI)

Syntax: LINES
Description: Source code lines will be listed in the symbol table included in the map file. This will
indicate the address that a particular source code line was located at, as an aid to
debugging.
Examples: LINES
Default: LINES
Category: Map file
See Also: NOLINES, NOPUBLICS, NOSYMBOLS, PUBLICS, SYMBOLS
11.31 MAP (MA)

Syntax: MAP
Description: Map file will contain a Link map showing the memory map of the application. The
memory map is shown as a list of segments with the address each segment is located
at, its length, memory type and relocation type.
Examples: MAP
Default: MAP
Category: Map file
See Also: NOMAP
- 75 - F
11.32 MEMOFFS (MO)

Syntax: MEMOFFS(segment(offset) [,segment(offset)][…])
Description: Applies an offset to the addresses used to access a segment.
For example if a segment is located at 1000H, then applying an offset of 0100H will not
relocate the segment, however any LJMP or LCALL instructions to the segment will
instead use the address 1100H.
This is useful for devices with a Memory Management Unit that execute code at a
different address to the physical address.
Examples: MEMOFFS(?PR?MAIN?DRWS(0x2000))
Applies an offset of 2000H to accesses to the ?PR?MAIN?DRWS segment.
MEMOFFS(?XD?FOO(0x410),?XD?BAR(0x500))
Applies offsets to accesses to two XDATA segments.
Default: No offsets are applied to addresses that refer to segments.
Category: Memory
11.33 MOVEABSCODE (MAC)

Syntax: MOVEABSCODE(originaladdress(newaddress)
[,originaladdress(newaddress)][…])
Description: Allows an absolute CODE segment to be moved from one location to another.
Examples: MOVEABSCODE(000Bh(800Bh))
Absolute segment located at 000Bh will be moved to 800Bh.
MOVEABSCODE(0x000B(0x800B)) Same as above.
MOVEABSCODE(0x0000(0x1000),0x000B(0x100B))
Moves the absolute segments at 0000H and 000B to 0x1000 and 0x100B
respectively.
Default: Segments are located by the Linker at addresses either specified in the project or by the
segments purpose (i.e. vectors)
See Also: ABSOLUTECODEOFFS, CODE, STARTCODE
11.34 NAME (NA)

Syntax: NAME(modulename)
Description: Specifies the module name of the output module.
Examples: NAME(FOO)
Default: NAME(module_name_of_first_module_linked).
For example if the first module in the list of modules to link together is named MAIN then
the default will be NAME(MAIN).
See Also: FLASHNAME, PRINT, TO
- 76 -
11.35 NOAMAKE (NOAM)

Syntax: NOAMAKE
Description: This directive has no effect and is included only for Keil compatibility.
Examples: NOAMAKE
Default: AMAKE
See Also: AMAKE
11.36 NOBRIDGE (NOBR)

Syntax: NOBR(type,name[,name][…])
Description: Tells the linker to NOT generate Bridges. A Bridge is a section of code that performs the
bank switch when a function in a Code Bank is called.
Bridges are not required for accessing constants in CODE memory, instead the access
function method should be used as described in the chapter 8 Code Banking. When
using C the Linker can determine which symbols do not require bridges. However, when
using Assembly, the Linker cannot determine this and generates bridges for all public
symbols in CODE space. This results in wasted memory and NOBR may be used to
specify that a bridge should not be generated for specific symbols.
Type may be SYMBOL, SEGMENT or AREA. The following list is either a list of
symbols, segment names or areas.
Examples: NOBR(SYMBOL, myconsts)
Default: Bridges are generated
See Also: BANKMODE
11.37 NOCASESENSITIVE (NOCS)

Syntax: NOCASESENSITIVE
Description: Turns off Case Sensitivity in the Linker. ANSI C is case sensitive. The variable FOO will
be the same variable as the variable foo. By default, OMF-51 file format that is used for
the object file is not case sensitive and FOO and foo will end up referencing the same
variable. This directive must appear before the list of input modules on the command
line so the Linker knows that it must parse all object files not using case sensitivity.
Examples: NOCASESENSITIVE
Default: NOCASESENSITIVE (The Linker is not case sensitive)
See Also: -C, CASESENSITIVE
11.38 NODEBUGLINES (NODL)

Syntax: NODEBUGLINES
Description: C source code line numbers are omitted from the absolute object file generated by the
Linker. It will not be possible to debug using the C source code, however the size of the
absolute object file will be reduced.
Examples: NODEBUGLINES
Default: DEBUGLINES
See Also: DEBUGLINES,DEBUGPUBLICS,DEBUGSYMBOLS,NODEBUGPUBLICS,
NODEBUGSYMBOLS
- 77 - F
11.39 NODEBUGPUBLICS (NODP)

Syntax: NODEBUGPUBLICS
Description: Public symbols will be omitted from the absolute object file generated by the Linker.
Public symbols are symbols used by more than one module. It is not possible to view
and manipulate public symbols while debugging, however the size of the absolute object
file will be reduced.
Examples: NODEBUGPUBLICS
Default: DEBUGPUBLICS
See Also: DEBUGLINES, DEBUGPUBLICS, DEBUGSYMBOLS, NODEBUGLINES,
NODEBUGSYMBOLS
11.40 NODEBUGSYMBOLS (NODS)

Syntax: NODEBUGSYMBOLS
Description: Local symbols will be omitted from the absolute object file generated by the Linker. Local
symbols are symbols used by only one module. It will not be possible to view and
manipulate local symbols while debugging, however the size of the absolute object file
will be reduced.
Examples: NODEBUGSYMBOLS
Default: DEBUGSYMBOLS
See Also: DEBUGLINES, DEBUGPUBLICS, DEBUGSYMBOLS, NODEBUGLINES,
NODEBUGSYMBOLS
11.41 NODEFAULTLIBRARY (NLIB)

Syntax: NODEFAULTLIBRARY
Description: Linker will not automatically link in libraries when required.
Examples: NODEFAULTLIBRARY
Default: The Linker automatically links in libraries when required.
11.42 NOFCTPTRMANAG (NOFPM)

Syntax: NOFCTPTRMANAG
Description: In order to overlay variables the Linker must determine the call tree, I.e. which functions
are called by a particular function. The Linker has to ensure that variables are only
overlaid in functions that are never in the process of executing at the same time.
However, when function pointers are used the Linker works out which set of functions
could be called by the function pointer and avoids overlaying the variables in any of
those functions. This can lead to inefficiencies. Using this directive the Linker will not
attempt to manage function pointers while performing variable overlaying. Instead call
references must be manually created using the OVERLAY directive.
Examples: NOFCTPTRMANAG
Default: Function pointers are managed automatically.
Category: Memory
See Also: NOOVERLAY, OVERLAY
- 78 -
11.43 NOIXREF (NOIX)

Syntax: NOIXREF
Description: Cross-Reference file will not be generated by the Linker.
Examples: NOIXREF
Default: IXREF
Category: Map file
See Also: IXREF
11.44 NOLINES (NOLI)

Syntax: NOLINES
Description: Source code lines are omitted from the Symbol Table included in the map file.
Examples: NOLINES
Default: LINES
Category: Map file
See Also: LINES, NOPUBLICS, NOSYMBOLS, PUBLICS, SYMBOLS
11.45 NOMAP (NOMA)

Syntax: NOMAP
Description: Link map (which is the memory map of the application) is omitted from the map file.
Examples: NOMAP
Default: MAP
Category: Map file
See Also: MAP
11.46 NOOVERLAY (NOOL)

Syntax: NOOVERLAY
Description: Automatic variables are not overlaid to conserve RAM. All automatic variables are
allocated unique memory locations.
Examples: NOOVERLAY
Default: OVERLAY
Category: Memory
See Also: NOFCTPTRMANAG, OVERLAY
11.47 NOPRINT (NOPR)

Syntax: NOPRINT
Description: Map file will not be generated.
Examples: NOPRINT
Default: PRINT
Category: Map file
See Also: PRINT
- 79 - F
11.48 NOPUBLICS (NOPU)

Syntax: NOPUBLICS
Description: Public symbols are omitted from the symbol table in the map file generated by the
Linker.
Public symbols are symbols used by more than one module.
Examples: NOPUBLICS
Default: PUBLICS
Category: Map file
See Also: LINES, NOLINES, NOSYMBOLS, PUBLICS, SYMBOLS
11.49 NOSTATVARROM (NOSTATVARROM)

Syntax: NOSTATVARROM
Description: The segment that contains the initial values for the static variables is located in Flash
rather than ROM. This means that once the ROM is locked, additional initialized static
variables may be added to the project.
If the Flash memory is not available at startup then the STATVARROM directive must be
used to located the initial values in ROM.
Examples: NOSTATVARROM
Default: STATVARROM
Category: Flash
See Also: STATVARROM
11.50 NOSYMBOLS (NOSB)

Syntax: NOSYMBOLS
Description: Local symbols are omitted from the symbol table in the map file generated by the Linker.
Local symbols are symbols used by only one module.
Examples: NOSYMBOLS
Default: SYMBOLS
Category: Map file
See Also: LINES, NOLINES, NOPUBLICS, PUBLICS, SYMBOLS
- 80 -
11.51 OVERLAY (OL)

Syntax: OVERLAY[(segments !*)]
OVERLAY[(segment ~ segments)]
OVERLAY[(segment ! segments)]
Where segments is a list of segments: (segment[,segment][…]) or a single
segment name.
Description: Automatic variables will be overlaid in the BIT, DATA and XDATA memory spaces if
required, to conserve RAM.
The OVERLAY directive also provides the following functionality:
• Remove segments from the overlay process
• Remove call references between segments
• Add call references between segments
Examples:
OVERLAY
All functions whose automatic variables are suitable for overlaying will be overlaid.
OVERLAY(?PR?X1?FOO !*)
The automatic variables in the segment ?PR?X1?FOO will not be overlaid.
OVERLAY((?PR?X1?FOO,?PR?X2?FOO) !*)
The automatic variables in the segments ?PR?X1?FOO and ?PR?X2?FOO will not
be overlaid.
OVERLAY(?PR?MAIN?BAR ~ ?PR?X1?FOO)
Segment ?PR?MAIN?BAR calls segment ?PR?X1?FOO. This directive will remove
the call reference.
OVERLAY(?PR?MAIN?BAR ~ (?PR?X1?FOO,?PR?X2?FOO))
Segment ?PR?MAIN?.BAR calls segments ?PR?X1?FOO and ?PR?X2?FOO. This
directive will remove those call references
OVERLAY(?PR?MAIN?BAR ! ?PR?X1?FOO)
This directive adds a call reference to indicate that segment ?PR?MAIN?BAR calls
segment ?PR?X1?FOO.
OVERLAY(?PR?MAIN?BAR ! (?PR?X1?FOO,?PR?X2?FOO))
This directive adds call references to indicate that segment ?PR?MAIN?BAR calls
segments ?PR?X1?FOO and ?PR?X2?FOO.
Default: OVERLAY
Category: Memory
See Also: NOFCTPTRMANAG, NOOVERLAY
11.52 PAGE (PA)

Syntax: PAGE(segment[,segment][…])
Description: Page aligns the XDATA segments specified. The XDATA segments are located at the
lowest possible page.
Examples: PAGE(?XD?MAIN) Page aligns segment ?XD?MAIN
PAGE(?XD?MAIN,?XD?MAIN2) Page aligns segments ?XD?MAIN and ?XD?MAIN2
Default: No XDATA segments are page aligned.
See Also: INPAGE
- 81 - F
11.53 PDATA (PD)

Syntax: PDATA(addr|segment[(addr)][,segment[(addr)]][…])
Description: Specifies how relocatable PDATA segments should be located. The directive provides
If the first parameter is an address then no relocatable PDATA segments will be located
below that address.
If any segment names have a following address in parentheses then that segment will be
located at that address (provided no other segments are already located at that
If there are relocatable PDATA segments whose location or order of location is not
Examples: PDATA(24H)
Locates all relocatable PDATA segments at least 24H bytes from the start of the
PDATA area.
PDATA(0x24)
PDATA(36)
PDATA(36,?PD?MAIN)
Same as above, however the segment ?PD?MAIN is located first
PDATA(36,?PD?MAIN,?PD?MAIN2)
Same as above, however the segment ?PD?MAIN2 is located after segment ?PD?
MAIN
PDATA(36,?PD?MAIN(38))
Locates all relocatable PDATA segments at least 36 bytes from the start of the
PDATA area, however the segment ?PD?MAIN is located 38 bytes from the start of
the PDATA area.
PDATA(26,?PD?MAIN,?PD?MAIN2(20),?PD?MAIN3)
Locates all relocatable PDATA segments at least 26 bytes from the start of the
PDATA area, however the segment ?PD?MAIN2 is first located 20 bytes from the
start of the PDATA area, then segment ?PD?MAIN is located followed by segment ?
PD?MAIN3.
Default: PDATA(0000H)
See Also: BIT, CODE, DATA, IDATA, XDATA
11.54 POSTOPTI (POSTOPTI)

Syntax: POSTOPTI
Description: Instructs the Linker to generate additional information in the AOF file that can be used for
post-link optimization by the Code Compressor.
Examples: POSTOPTI
Default: Additional information is not included in the AOF file.
- 82 -
11.55 PRECEDE (PC)

Syntax: PRECEDE(segment[,segment][,…])
Description: Specifies relocatable segments that must be located before other relocatable segments
are located.
Examples: PRECEDE(?PR?MAIN?MYFILE)
Default: Segments are located according to an algorithm used by the Linker.
See Also: STACK
11.56 PRINT (PR)

Syntax: PRINT[(filename)]
Description: A map file is generated. If a filename is omitted the filename is based on the output
module name.
Examples: PRINT generates a map file using a filename based on the module name of the output
object file. For example if the output object file module name is MAIN then MAIN.M51 is
the filename of the generated map file.
PRINT(FOO.M51) generates a map file with the filename FOO.M51
Default: PRINT
Category: Map file
See Also: FLASHNAME, NAME, NOPRINT, TO
11.57 PUBLICS (PU)

Syntax: PUBLICS
Description: Public symbols will be listed in the symbol table in the map file generated by the Linker.
Public symbols are symbols used by more than one module. The symbols table shows
the location of each symbol as an aid to debugging.
Examples: PUBLICS
Default: PUBLICS
Category: Map file
See Also: LINES, NOLINES, NOPUBLICS, NOSYMBOLS, SYMBOLS
11.58 RAMSIZE (RS)

Syntax: RAMSIZE(size)
Description: Specifies the size of the IDATA area in bytes. This is useful if there is less than 256
bytes in your target microcontroller and you wish the Linker to generate an error if an
attempt is made to locate segments in non-existent locations.
Examples: RAMSIZE(128) Specifies an IDATA space 128 bytes in size
CODESIZE(80H) Same as above
CODESIZE(0x80) Same as above
Default: RAMSIZE(128)
Category: Memory
See Also: CODESIZE, RAMSIZEINIT, XDATASIZE
- 83 - F
11.59 RAMSIZEINIT (RSI)

Syntax: RAMSIZEINIT(bytes)
Description: Specifies how many bytes of IDATA starting at 00H should be initialized to zero before
the main function is executed.
Examples: RAMSIZEINIT(256) Initializes all 256 bytes of IDATA to zero
RAMSIZEINIT(0x100) Same as the above example
RAMSIZEINIT(100H) Same as the above example
Default: RAMSIZEINIT(128)
Category: Memory
See Also: RAMSIZE
11.60 REFLASH (REFLS)

Syntax: REFLASH([filename])
Description: Specifies the file where Flash information can be found when running in locked mode.
Examples: REFLASH(flsfile.fls)
Default: Flash is not used. But when used default is REFLASH(projectname.FLS)
Category: Flash
See Also: FLASH
11.61 RESERVE (RES)

Syntax: RESERVE(memoryspace,size)
Description: Reserves memory so the Linker does not locate segments in those reserved spaces.
Examples: RESERVE(DATA,5) Reserves five bytes in DATA memory
RESERVE(DATA,5H) Same as the example above
RESERVE(DATA,0x5) Same as the example above
RESERVE(BDATA,7) Reserves seven bytes in bit-addressable memory
RESERVE(BDATA,7H) Same as the example above
RESERVE(BDATA,0x7)Same as the example above
RESERVE(BIT,4) Reserves four bits in bit-addressable memory
RESERVE(BIT,4H) Same as the example above
RESERVE(BIT,0x4) Same as the example above
Default: Flash functionality is not enabled
Category: Flash
11.62 SEGMENTOVERLAY (SO)

Syntax: SEGMENTOVERLAY (segment1, segment2,…segmentn )
Where segment1, segment2 and segmentn are segments that can be overlaid:
Description: This allows to do manual overlays of assembler modules
Examples: SEGMENTOVERLAY(?PR?X1?FOO,?PR?X2?FOO)
Default: Manual overlay are not used
Category: Memory
See Also: OVERLAY, NOOVERLAY
- 84 -
11.63 STACK (ST)

Syntax: STACK(segment[,segment][,…])
Description: The relocatable segments specified are located after all other relocatable segments
have been located.
Examples: STACK(?ID?STK)
Default: Segments are located according to an algorithm used by the Linker.
See Also: PRECEDE
11.64 STARTCODE (STCO)

Syntax: STARTCODE(address)
Description: Specifies a start address below which no relocatable segments will be located
Examples: STARTCODE(1000H) Locates all relocatable CODE segments at least 1000H bytes
from the start of the code area.
STARTCODE(0x1000) Same as the above example.
STARTCODE(4096) Same as the above example.
Default: STARTCODE(0000H)
See Also: ABSOLUTECODEOFFS, CODE, MOVEABSCODE
11.65 STATVARROM (STATVARROM)

Syntax: STATVARROM
Description: The segment that contains the initial values for the static variables is located in ROM
rather than Flash. This means that once the ROM is locked, no initialized static variables
may be added to the project. If the Flash memory is not available at startup then this
directive must be used.
Examples: STATVARROM
Default: STATVARROM
Category: Flash
See Also: NOSTATVARROM
11.66 SYMBOLS (SB)

Syntax: SYMBOLS
Description: Local symbols will be listed in the symbol table in the map file generated by the Linker.
Local symbols are symbols used by only one module. The symbols table shows the
location of each symbol as an aid to debugging.
Examples: SYMBOLS
Default: SYMBOLS
Category: Map file
See Also: LINES, NOLINES, NOPUBLICS, NOSYMBOLS, PUBLICS
- 85 - F
11.67 TO (TO)
Syntax: TO(filename)
Description: Specifies the output filename of the generated absolute object file.
Examples: TO(FOO) Generates an absolute object file with the filename FOO
TO(FOO.AOF) Generates an absolute object file with the filename FOO.AOF
Default: TO(filename_based_on_first_module_name)For example if the first module
linked has the name FOO then the generated absolute object file will have the filename
FOO.
See Also: FLASHNAME, NAME, PRINT
11.68 XDATA (XD)

Syntax: XDATA(addr|segment[(addr)][,segment[(addr)]][…])
Description: Specifies how relocatable XDATA segments should be located. The directive provides
If the first parameter is an address then no relocatable XDATA segments will be located
below that address. If any segment names have a following address in parentheses then
that segment will be located at that address (provided no other segments are already
located at that address). The address may be below the start address specified. The
remaining segments specified are located in the order that they are specified. If there are
relocatable XDATA segments whose location or order of location is not important then
they may be omitted from the list of segments specified with this directive. The start
address will be applied to them however.
Examples: XDATA(24H)
Locates all relocatable XDATA segments at least 24H bytes from the start of the
XDATA area. If the first parameter is an address then no relocatable XDATA
segments will be located below that address.
XDATA(0x24) Same as the above example
XDATA(36) Same as the above example
XDATA(36,?XD?MAIN)
Same as above, however the segment ?XD?MAIN is located first
XDATA(36,?XD?MAIN,?XD?MAIN2)
Same as above, however the segment ?XD?MAIN2 is located after segment ?XD?
MAIN
XDATA(36,?XD?MAIN(38))
Locates all relocatable XDATA segments at least 36 bytes from the start of the
XDATA area, however the segment ?XD?MAIN is located 38 bytes from the start of
the XDATA area.
XDATA(26,?XD?MAIN,?XD?MAIN2(20),?XD?MAIN3)
Locates all relocatable XDATA segments at least 26 bytes from the start of XDATA
area, however the segment ?XD?MAIN2 is first located 20 bytes from the start of the
XDATA area, then segment ?XD?MAIN is located followed by segment ?XD?MAIN3.
Default: XDATA(0000H)
See Also: BIT, CODE, DATA, IDATA, PDATA
- 86 -
11.69 XDATASIZE (XSIZE)

Syntax: XDATASIZE(size)
Description: Specifies the size of the XDATA area in bytes. This is useful if there is less than 64K in
your target hardware and you wish the Linker to generate an error if an attempt is made
to locate segments in non-existent locations.
Examples: XDATASIZE(32768) Specifies an XDATA space 32768 bytes in size (32K)
XDATASIZE(8000H) Same as above
XDATASIZE(0x8000) Same as above
Default: XDATASIZE(65536)
Category: Memory
See Also: CODESIZE, RAMSIZE
- 87 - F
12. Appendix B. Ride7 Linker options reference LX51
12. Appendix B. Ride7 Linker options reference
This Appendix provides an overview of the Linker options in Ride7. A screen shot of each subsection is
provided along with a description of each option in the subsection.
The Linker options may be accessed in Ride7 by choosing Options | Project Properties then
expanding the LX51 portion of the tree and selecting the subsections.
12.1 Linker settings
12.1.1 General
Option Description of General linker setting Directive

Use RC51 libraries The libraries supplied with the toolset will be (none)/NLIB
used.
Generate debug Debugging information will be included in the DL + DP + DS/NODL +

information absolute object file. NODP + NODS
Generate Intel Hex file An Intel Hex file can be generated.

Generate a binary file A raw binary file can be generated.
- 88 -
LX51 12. Appendix B. Ride7 Linker options reference
12.1.2 Memory
Option Description of Memory linker setting Directive

RAM size Amount of internal RAM on the device. RS (size)
Initialized RAM size Amount of internal RAM to initialize to 0. RSI (size)
Code size Maximum code memory size CODESIZE (CSIZE)
Xdata size Maximum Xdata memory size XDATASIZE (XSIZE)
Code starting address Start address for CODE segments. Note that it CODE (address)
does not specify a start address for the reset
vector or interrupt vectors.
Xdata starting address Start address for the external RAM (XDATA) XDATA (address)
segments.
Idata starting address Start address of the indirect internal RAM IDATA (address)
(IDATA) segments.
Data starting address Start address of the direct internal RAM DATA (address)
(DATA) segments. Note that it does not affect
the location of the register banks.
Bit starting address Start address of the internal bit-addressable BDATA (address)
area (BDATA).
Absolute code address Offset to apply to absolute CODE segments. ABSCODEOFFS (offset)
12.1.3 Map file (Linker listing)
Option Description of Map file linker setting Directive

Generate map file Descriptions of the DATA and CODE MAP/NOMAP
segments will be included in the listing file.
Generate cross Cross reference table will be included in the IX/NOIX
references listing file.
- 89 - F
12. Appendix B. Ride7 Linker options reference LX51
12.1.4 Startup
Option Description of Startup linker setting

Startup type Specifies Startup type: default/user defined/micro-specific.
Default Startup Use the startup file from the standard libraries. Checked by default.
User defined Startup Do not include the default startup file. The user uses their own startup file
which must be included in the project.
Micro-specific Startup A copy of the default startup file is made and included in the project. Some
additional code can be added in the ‘Micro-specific initialization code’
window.
External stack size When using an external re-entrant stack this specifies the size of the stack.
Initial value of timer 1 In the startup code timer 1 is initialized to be used as a baud rate generator.
This option allows the initial value to be changed therefore changing the
baud rate.
12.1.5 Bank switching, Flash mode, KR-51 Kernel

These options have simple Yes/No choices.
12.1.6 Addition options

Linker directives may be entered into the Additional options box in the form of a space separated list.
Moreover, you can specify a file containing the different directives.
For example: @directives.txt
with directives.txt containing: XDATA(0x1000) PDATA(0x2001)
In this file the ampersand character (&) allows to add comments after PUBLICS &Insert public symbols
into the symbol table.
Note: You should not specify a directive that will already be specified by selection or non-selection of a
linker option in one of the sections previously described.
- 90 -
LX51 13. Appendix C. Warning messages
13. Appendix C. Warning messages
Warning Description
WARNING 1: UNRESOLVED EXTERNAL SYMBOL
Cause: The Linker is unable to find the declaration of a symbol. Usually a variable is
declared as extern in one source file but the user forgets to actually declare the
variable in one of the source files, or the extern keyword is included by mistake in a
variable declaration.
Resolution:The Linker will display the symbol name, which is usually a variable or
function name and the object file or module that the symbol is referenced in.
Ensure the variable or symbol is declared somewhere in the project or remove the
erroneous extern keyword.
WARNING 2: REFERENCE MADE TO UNRESOLVED EXTERNAL
Cause: The Linker is unable to find the declaration of a symbol. Usually a variable is
declared as extern in one source file but the user forgets to actually declare the
variable in one of the source files, or the extern keyword is included by mistake in a
variable declaration.
This is similar to warning 1, however it indicates that the variable or function that
cannot be resolved is actually used in the project. There is the potential for the code to
behave in an undefined manner.
Resolution: The Linker will display the symbol name, which is usually a variable or
function name and the object file or module that the symbol is referenced in.
Ensure the variable or symbol is declared somewhere in the project or remove the
erroneous extern keyword.
WARNING 3: ASSIGNED ADDRESS NOT COMPATIBLE WITH ALIGNMENT
Cause: An attempt has been made to locate a segment at an address that conflicts
with the segment alignment. For example if a segment is Page aligned and an attempt
is made to locate the segment at 0101H then the warning will be generated at 0101H is
not a page aligned address.
Resolution: The warning message will indicate the segment in question. Modify the
address the segment is being located at so it is compatible with the alignment. The
Linker provides optimum performance and allows the greatest flexibility if segments
are only aligned when absolutely necessary.
WARNING 4: CODE SPACE MEMORY OVERLAP
Cause: The Linker has determined that some memory locations would be occupied by
more than one segment. The generated executable code will fail if an attempt is made
to execute one of the functions involved or read the constant data involved.
This is commonly caused by a clash in the starting locations of relocatable segments
that have been located using the CODE directive and/or absolutely located constant
data and/or absolute CODE segments (such as an interrupt vector).
- 91 - F
13. Appendix C. Warning messages LX51
Warning Description
Resolution: The Warning message indicates the memory location where the overlap
occurred. Check the Link map in the map file to determine which segments are
overlapping. Refer to section 4.3.Segment Naming Conventions to work out which
parts of the project are overlapped and change one of the addresses specified. Also
double-check the use of the CODE directive to ensure all segments are located at the
correct locations. One or more of the segments may have to be located elsewhere
depending on the project.
WARNING 5: XDATA SPACE MEMORY OVERLAP
to the data involved.
that have been located using the XDATA directive and/or absolutely located XDATA
data.
double-check the use of the XDATA directive to ensure all segments are located at the
WARNING 6: DATA SPACE MEMORY OVERLAP
to the data involved.
that have been located using the DATA directive and/or absolutely located DATA data
and/or the register banks.
double-check the use of the DATA directive to ensure all segments are located at the
WARNING 7: MODULE NAME NOT UNIQUE
Cause: Each source file generates an input module, whose name is derived from the
source file name. For example FOO.C generates a module called FOO. If a project
includes two modules with the same name then this warning is generated.
This situation can arise if a project contains a C source file and an assembler source
file with the same file name (excluding the extension), for example FOO.C and
FOO.A51. Also, although less likely, if a project contains a source file whose name just
happens to match a library module.
Resolution: The Warning message will indicate the module name that is not unique.
Rename the source file that generated the module and rebuild.
WARNING 11: EXTERNAL STACK LENGTH TOO LARGE, 256 ASSUMED
- 92 -
LX51 13. Appendix C. Warning messages
Warning Description
Cause: A size greater than 256 bytes has been specified for the external stack, and the
Linker has altered the size of the external stack to the maximum size of 256 bytes.
Resolution: Ensure that in the Linker options in Ride7 the external stack size is 256
bytes or less.
WARNING 12: UNKNOWN RECORD TYPE, RECORD IGNORED
Cause: The relocatable object files contain records as a method to store information.
Different types of information are stored in different records. This warning indicates
that the object file contained a record that the Linker did not recognize, and has
therefore ignored the record. This could result in non-functional code.
Resolution: Ensure that the Linker is attempting to link the correct object files,
generated by the Raisonance tools.
Try deleting all the .obj object files and recompiling/reassembling to ensure new object
files are generated.
Also try copying the source files and Project files only to a new directory and rebuilding.
WARNING 14: MULTIPLE CALL TO SEGMENT
This warning is a result of an internal error when performing the overlaying of
automatic variables. Please contact Raisonance for assistance if you see this error.
WARNING 16: UNCALLED SEGMENT: IGNORED FOR OVERLAY PROCESS
Cause: An executable CODE segment containing automatic variables is not called
from anywhere in the application. Therefore the automatic variables cannot and have
not been overlaid with the automatic variables of other functions, which may reduce
RAM usage.
Resolution: Refer to t section 4.3.Segment Naming Conventions to find out which
function is not being called. If a function call has been omitted then add it to the source
code.
However, if the function is not supposed to be called then this warning can be treated
as informational, warning you that not calling the function is resulting in potentially
more RAM being used than is necessary. If the function is a debug function then
surround it with conditional compilation so it is only included when debugging is
required and it will therefore be called from somewhere.
WARNING 18: CONTROL DIRECTIVE IGNORED
Cause: The compiler or assembler POSTOPTI directive is being used indicating the
linker should use the Code Compressor, however the current license does not allow
the Code Compressor to execute.
Resolution: Remove the directive or contact Raisonance to upgrade your tools to
include the Code Compressor.
WARNING 21: EMPTY RELOCATABLE SEGMENT
This warning is the result of an internal error in the assembler or compiler.
- 93 - F
14. Appendix D. Error messages LX51
14. Appendix D. Error messages
Error Description
ERROR 100: UNRESOLVED EXTERNAL
Cause: The Linker is unable to find the declaration of a symbol. Usually a variable is declared
as extern in one source file but the user forgets to actually declare the variable in one of the
source files, or the extern keyword is included by mistake in a variable declaration.
Resolution: The Linker will display the symbol name, which is usually a variable or function
name and the object file or module that the symbol is referenced in.
Ensure the variable or symbol is declared somewhere in the project or remove the erroneous
extern keyword.
ERROR 101: SEGMENT COMBINATION ERROR
Cause: Partial segment with different attributes has been found. The attributes concern memory
class index or relocation type. For example:
main.a51:
?MYSEG SEGMENT CODE INBLOCK
main2.a51:
?MYSEG SEGMENT CODE
Resolution: The error message indicates which symbol has the problem. The symbol name
matches the segment name, so it is easy to check all segment declarations to ensure they are
identical.
ERROR 102: EXTERNAL ATTRIBUTES MISMATCH
Cause: A variable is declared as an extern in more than one module, however the memory
spaces of the declarations do not match. For example:
main.c:
extern char idata x;
main2.c:
extern char xdata x;
matches the variable name, so it is easy to check all extern declarations of that variable to
ensure they are identical.
ERROR 103: EXTERNAL ATTRIBUTES DO NOT MATCH PUBLIC
Cause: A variable is declared as extern in a module, however the memory space in the
declaration does not match the memory space of the actual variable declaration. For example:
main.c:
char idata x;
main2.c:
extern char xdata x;
matches the variable name, so it is easy to check all extern declarations of that variable to
ensure they are identical to the actual declaration.
- 94 -
LX51 14. Appendix D. Error messages
Error Description
ERROR 104: MULTIPLE PUBLIC DEFINITIONS
Cause: A variable with external linkage has been declared in more than one module. Omitting
the ‘extern’ keyword from an extern declaration can cause this. For example:
main.c:
char idata x;
main2.c:
char idata x;
matches the variable name, so it is easy to check all declarations of that variable to ensure they
are correct.
ERROR 106: SEGMENT OVERFLOW
Cause: This error indicates that a segment cannot be fit inside the memory space, for example
a DATA segment that is bigger than 128 bytes or an XDATA segment that is bigger than 65536
bytes.
Resolution: The error message indicates which segment has the problem. The symbol name
matches the segment name, so it is easy to check all declarations of that segment.
ERROR 107: ADDRESS SPACE OVERFLOW
Cause: The segments for a particular memory space are too large to all fit into memory. For
example this error will be generated if the source code results in more than 64K of code, and
Code Banking is not being used.
Resolution: The error message indicates the memory space that has overflowed. Reduce the
requirements on that memory space by optimizing the source code or removing unused
sections.
For example if the XDATA memory space has overflowed, then there may be some data that
can be moved to CODE memory space and uses as constants or stored in a serial memory
device.
If the CODE memory space has overflowed then ensure the highest level of optimization is
being used. Try changing the optimization settings to favor size. Look for places in the source
code that can be optimized. Also consider using Code Banking as a possible last resort.
If the PDATA, IDATA or DATA memory space has overflowed then look to see which variables
may be moved to the other memory spaces. Remember that DATA is the fastest memory,
followed by IDATA, PDATA then XDATA. Less frequently accessed variables are more suitable
to be stored in slower memory. Also check to see if the device features on-chip XDATA that can
be used.
ERROR 108: SEGMENT IN LOCATING CONTROL CANNOT BE ALLOCATED
Cause: When using Code Banking whole modules are located into banks. However, if a module
contains one or more absolute segments then this error will be generated.
This error may also be generated if you try to relocate any segment that is absolute or already
relocated with directives such as DATA, IDATA, XDATA, CODE, INPAGE or PAGE.
Resolution: Ensure that any absolute variables inside source files that are located in a Code
Bank are placed in a separate source files of their own.
Double-check that no segments are located twice with two different directives, or no attempt is
being made to relocate an absolute segment using DATA, IDATA, XDATA, CODE, INPAGE or
PAGE.
- 95 - F
Error Description
ERROR 109: EMPTY RELOCATABLE SEGMENT
Cause: This error is generated as the result of an internal error in the assembler or compiler.
Resolution: Please contact Raisonance for assistance.
ERROR 110: CANNOT FIND SEGMENT
Cause: A directive specifies a segment that does not exist. Commonly this is caused by a typo
in a segment name.
Resolution: The error message indicates the segment that cannot be found. Compare its name
with the segments that do exist in the project. They are listed in the Link map in the map file.
Please refer to section 5.4.Link map for information on reading the Link map. Please refer to
section 4.3.Segment Naming Conventions for other information.
ERROR 111: SPECIFIED BIT ADDRESS NOT ON BYTE BOUNDARY
Cause: The Linker has attempted to relocate a bit of a byte into the bit-addressable space,
however the address selected for the byte was not in the bit-addressable space (20H – 2FH).
Resolution: Ensure there is enough space free in the bit-addressable space. If necessary use
bit-fields for less frequently accessed bits, locating them in DATA memory or IDATA memory.
ERROR 112: SEGMENT TYPE NOT LEGAL FOR COMMAND
Cause: This error occurs when a segment specified with a directive such as CODE, XDATA,
: DATA, etc has the wrong memory space for that directive. For example, attempting to relocate
a code segment using the XDATA directive will generate this error.
Resolution: The error message indicates which segment has the problem. Look to find out
which directives the segment is specified with and remove the segment name or correct the
mistake.
ERROR 113: ABSOLUTE SEGMENT RELOCATION NOT ALLOWED
Cause: This error occurs when the user wants to relocate an absolute segment. An absolute
segment, having a forced address cannot be relocated (its address cannot be changed).
Resolution: Either do not try to relocate the absolute segment, or do not specify this segment as
absolute.
ERROR 115: INPAGE SEGMENT IS GREATER THAN 256 BYTES
Cause:An attempt has been made to relocate a segment using the INPAGE directive, but the
segment size is greater than 256 bytes (the size of a page) and therefore cannot fit inside a
page.
Resolution: The error message indicates which segment has the problem.
Either do not specify the segment with the INPAGE directive, or move some of the variables in
the segment into another segment, which can also be located using the INPAGE directive.
ERROR 116: INBLOCK SEGMENT IS GREATER THAN 2048 BYTES
Cause: The linker tries to locate a segment with the INBLOCK attribute, however the segment
size is greater than 2048 bytes and therefore the code may not execute properly.
This error is generated because the INBLOCK segment makes use of AJMP and ACALL
instructions. Both these instructions only allow 10-bit addressing and therefore can only jump to
or call an address within 2k of the instruction’s address.
- 96 -
Error Description
Resolution: The error message indicates which segment has the problem. If the segment was
written in assembler then split it up into smaller segments.
If the segment was generated by the compiler then using the segment naming conventions to
work out which function generated the segment. Split the function up into smaller segments.
ERROR 119: REFERENCE MADE TO ERRONEOUS SEGMENT
Cause: Bank switching relies on a library segment called ?BANK?SWITCH. If this special
segment cannot be found then this error is generated.
Resolution: Ensure the environment options are correctly set so that the Library path points to
the LIB folder in the Ride7 installation.
Try uninstalling and reinstalling the tools to a new folder.
ERROR 121: IMPROPER FIXUP
Cause: When the Linker attempted to resolve a relocatable address used in an ACALL, AJMP
or relative jump instruction (JB, JNB, JC, JNC, SJMP, etc) – called a fixup - the address was
found to be out of the address range allowed by the instruction. For example ACALL instructions
can only jump to a location within the same 2048 byte block.
Resolution: The error gives the absolute address of the instruction whose address fixup failed.
The following steps determine the exact location in your code that the problem occurs:
Look at the Link map in the map file to determine which segment the absolute address is inside
of. Referring to the segment naming conventions in you can determine which function contains
the problem.
Take away the absolute address from the start address of the segment to obtain an offset into
the segment of the problem. For example if the absolute address given by the error was 0015H
and the segment starts at 0013H, the offset is 0015H – 0013H = 0002H.
Open the compiler listing file for the source file that contains the function and locate the
assembly listing for that function.
The first value on each assembler line is the offset into the function. For example the following
might be found for an offset of 0002H:
SOURCE LINE # 13
0002 1100 R ACALL foo ;
The instruction on the line is the one whose address fixup failed. In the example above the start
of the function foo must be more than 2048 bytes away from the ACALL instruction.
If the microcontroller you are using supports LCALL and LJMP instructions then switch from the
Tiny memory model to the Small memory model. If the problem occurs with a relative jump
instruction then reduce the size of the function by splitting it into smaller functions.
ERROR 122: CANNOT FIND MODULE
Cause: An attempt is being made to link with a module that cannot be found. A missing library
object file for example or an incorrectly entered command line could cause this.
Resolution: Ensure that all object files specified exist. Try copying the source files and Project
file to an empty directory and rebuilding.
If a library module is missing then try reinstalling the tools and rebuilding.
ERROR 124: RESERVED
This error is reserved for future use.
ERROR 125: RESERVED
- 97 - F
Error Description
This error is reserved for future use.
ERROR 128: NOBRIDGE OPTION USED WITHOUT CODE BANKING
Cause: The NOBR directive has been used without any other Code Banking directive.
Resolution: Either remove the NOBR directive or insert the necessary code banking directives
into the command line. If using Ride7 then check the option to use Code Banking.
ERROR 129: CANNOT FIND FUNCTION
Cause: A function specified using the OVERLAY directive could not be found in the project
Resolution: The error message indicates which function cannot be found. Check the Link map
in the map file to see which functions are present in the project and modify the OVERLAY
directive accordingly.
ERROR 130: CODE SPACE OVERLAP
Cause: The Linker has determined that some memory locations would be occupied by more
than one segment. The generated executable code will fail if an attempt is made to execute one
of the functions involved or read the constant data involved. This is commonly caused by a
clash in the starting locations of relocatable segments that have been located using the CODE
directive and/or absolutely located constant data and/or absolute code segments (such as an
interrupt vector).
Resolution: The Warning message indicates the memory location where the overlap occurred.
Check the Link map in the map file to determine which segments are overlapping. Refer to the
segment naming conventions to work out which parts of the project are overlapped and change
one of the addresses specified. Also double-check the use of the CODE directive to ensure all
segments are located at the correct locations. One or more of the segments may have to be
located elsewhere depending on the project.
ERROR 132: FIXUP OUTSIDE OF THE CODE SEGMENT LIMITS
Cause: This error is generated by an internal error of the compiler or assembler and means that
a symbol is referred to which is outside of the current code segment.
Resolution: Contact Raisonance for assistance.
ERROR 133: CANNOT FIND SYMBOL
Cause: This error occurs when using Flash mode. A symbol that was previously defined as
being in the ROM section was not found during the build.
Resolution: Once the ROM part is locked it must not change. Unlock the ROM part and rebuild
the project.
ERROR 134: SYMBOL ALREADY RELOCATED
Cause: This error occurs when a new build of the Flash section relocates a symbol located in
the ROM section, while using Flash mode.
Resolution: The error message indicates which symbol is being relocated. Ensure that variables
that are located in the ROM section once locked are not included in the Flash section.
ERROR 135: BANK SWITCHING IS NOT COMPATIBLE WITH CODE COMPRESSOR
Cause: This error occurs when using Bank Switching mode if the option Generate Post-
optimizing Information is checked in the Options|Target|Properties menu
- 98 -
Error Description
Resolution: Use either Bank Switching mode or Code Compressor option.
ERROR 136: FLASH IS NOT COMPATIBLE WITH CODE COMPRESSOR
Cause: This error occurs when using Flash mode if the option Generate Post-optimizing
Information is checked in the Options|Target|Properties menu.
Resolution: Use either Flash mode or Code Compressor option.
- 99 - F
15. Appendix E. Fatal error messages LX51
15. Appendix E. Fatal error messages
Error Description
FATAL 201: INVALID COMMAND LINE SYNTAX
Cause: The Linker has been invoked from the command line, however the command was
incorrectly specified.
Resolution: The error message will indicate where the error occurred on the command line.
Refer to the directives reference in this manual and the command line syntax to located the
mistake and correct it.
FATAL 202: INVALID COMMAND LINE: TOKEN TOO LONG
Cause: The Linker has been invoked from the command line, however the command line was
longer than the maximum allowed by DOS.
Resolution: Use a Command file. A Command file is a plain text file that contains all the
command line arguments for the Linker. The arguments may be split into multiple lines if an
ampersand is placed at the end of each line.
Example command line: LX51 main.obj,main2.obj TO(main.aof)
Place command line arguments in a text file:
myproject.cmd:
Main.obj, main2.obj &
TO(main.aof)
Then invoke using the Command file: LX51 @myproject.cmd
FATAL 203: EXPECTED ITEM MISSING

Cause: The Linker was invoked on the command line, however a non-optional component of
the command line was missing, for example an object file.
Resolution: Double-check the command line arguments to ensure they match the allowed
syntax. You may find the syntax in Chapter 3.
FATAL 204: INVALID KEY WORD
Cause: An attempt has been made to use a directive that does not exist. This can easily occur if
a directive was typed.
Resolution: The error message will indicate the offending directive. Double-check that it does
exist and is listed in Appendix A of this manual.
FATAL 206: INVALID CONSTANT
Cause: Some directives require a value to be specified, for example the PDATA directive. This
error is generated if the value specified is invalid, for example: PDATA(X)
Resolution: The error indicates the directive concerned. Check the use of that directive. If the
Linker is being run from the command line then check the way you are using that directive. If
the Linker is being run from Ride7 then carefully check the Linker options. Appendix B will aid in
determining which Ride7 option uses the directive concerned.
FATAL 210: INVALID INCLUDE FILE
- 100 -
LX51 15. Appendix E. Fatal error messages
Error Description
Cause: This error is generated if an invalid module is specified using the BANK or FLASH
directives.
Resolution: The error indicates the invalid module. Ensure that all modules specified exist and
were generated by the Raisonance tools. Try deleting all object file and rebuilding the project.
Try copying the source files and Project file to an empty directory and rebuilding the project.
FATAL 211: CODE BANKING SEGMENT MISSING OR INVALID
Cause: Bank Switching requires the use of a special library segment named ?BANK?SWITCH.
If the special segment cannot be found then this error is generated.
Resolution: Ensure the environment options are correctly set so that the Library path points to
the LIB folder in the Ride7 installation. Try uninstalling and reinstalling the tools to a new folder.
FATAL 214: INPUT PHASE ERROR
Cause: The Linker reads object files more than once while linking. This error indicates that for
some reason the object file has changed between passes.
Resolution: This error usually indicates an internal error in the Linker. Please contact
Raisonance for assistance.
FATAL 216: INSUFFICIENT MEMORY
Cause: The Linker ran out of memory while linking a project.
Resolution: Close some applications and try again to link the project. Press Ctrl-Alt-Delete and
check to make sure there are no unnecessary hidden tasks running.
FATAL 218: NOT AN OBJECT FILE
Cause: An attempt has been made to link a file that is not a valid object file or library file.
Resolution: Check to ensure that the Linker is linking the desired object files and library files. If
they are all correct, then delete the object file/library file and recompile/reassemble the source
file to generate new object files/library files. Try copying the source files and Project file to an
empty directory and rebuilding, to ensure no other files are being included by mistake.
FATAL 219: NOT AN 8051 OBJECT FILE
Cause: An attempt has been made to link a file that is not a valid 8051 object file or library file
Resolution: Check to ensure that the Linker is linking the desired object files and library files. If
they are all correct, then delete the object file/library file and recompile/reassemble the source
file to generate new object files/library files.
Ensure the project is set up for an 8051, not a different microcontroller family.
Try copying the source files and Project file to an empty directory and rebuilding, to ensure no
other files are being included by mistake.
FATAL 220: INVALID INPUT MODULE
Cause: An attempt is being made to link with an invalid input module.
Resolution: Ensure that the Raisonance tools generated all the object files being linked. Try
deleting all object files and rebuilding the project. Try copying the source files and Project file to
an empty directory and rebuilding. If the error persists then an internal error in the compiler or
assembler may be causing this problem. Contact Raisonance for assistance.
FATAL 221: MODULE SPECIFIED MORE THAN ONCE
- 101 - F
15. Appendix E. Fatal error messages LX51
Error Description
Cause: An attempt was made to link the same module more than once. This can be caused by
accidentally specifying the same object file twice on the command line.
Resolution: The error will indicate the offending module/source file. Check the project to ensure
it is only linked once. If using the command line then either modify one copy of the filename or
remove it.
FATAL 222: SEGMENT SPECIFIED MORE THAN ONCE
Cause: This error is caused by the same segment name being used inside both library code
and the user’s application.
Resolution: The error message indicates the segment name causing the problem. If using the
compiler then refer to the segment naming conventions to determine which part of the project is
generating the segment. Either the source file or function name will have to be renamed (if
applicable). If the assembler is being used then rename the segment to something else.
FATAL 224: DUPLICATE KEY WORD
Cause: This error is generated when a directive that may only be specified once is specified
more than once. For example: LX51 test.obj TO(test.aof) TO(test.aof)
The error message will indicate the directive that is duplicated.
Resolution: Carefully check the Linker command line to find the duplicate directive specified in
the error message and remove it.
FATAL 226: SEGMENT ADDRESS INVALID FOR CONTROL
Cause: The address specified in a relocating directive is out of range. For example
CODE(0x10000) will generate this error.
Resolution: The error message indicates the directive with the invalid address. If using the
command line modify the directive to correct the problem. If using Ride7 locate the control that
uses the directive and modify the setting accordingly.
FATAL 227: PAGEWIDTH PARAMETER OUT OF RANGE
Obsolete error – depricated directive.
FATAL 228: RAMSIZE PARAMETER OUT OF RANGE
Cause: More than 256 bytes of internal RAM have been specified.
Resolution: Modify the option in Ride7 or the value specified on the command line using the
RAMSIZE directive, to ensure that 256 bytes or less of internal RAM is specified.
FATAL 235: FLASHBANKAREA/BANKAREA PARAMETER OUT OF RANGE
Cause: The start address specified using the FLASHBANKAREA or BANKAREA directive is
higher than the end address specified with the same directive.
Resolution: Double check all uses of the FLASHBANKAREA and BANKAREA directives and
their associated Ride7 options to ensure that the desired addresses are used.
FATAL 237: MAXIMUM OBJECT SIZE REACHED
Cause: The evaluation version of the tools are being used which have a limit on the amount of
code that may be generated, for example 4Kb. This error is generated when the limit is
reached.
Resolution: Upgrade to the full version of the tools which do not have a code size limit.
- 102 -
LX51 15. Appendix E. Fatal error messages
Error Description
FATAL 239: ILLEGAL USE OF KERNEL
Cause: Some versions of the tools do not include a license to use the Kernel. If this error
message is generated then an attempt has been made to use the Kernel in a version that does
not allow it to be used.
Resolution: Upgrade to a version that includes a license to use the Kernel.
FATAL 240: INTERNAL PROCESS ERROR
Cause: This error is generated as a result of an internal error during linking.
FATAL 243: LITE VERSION: MAXIMUM OBJECT SIZE REACHED
Cause: The Lite version of the tools are being used which have a limit on the amount of code
that may be generated, for example 32Kb. This error is generated when the limit is reached.
Resolution: Upgrade to the full version of the tools which do not have a code size limit.
FATAL 245: UNKNOWN FIXUP
Cause: This error is generated by a relocatable address in the object file that cannot be
resolved, and is the result of an internal error.
FATAL 246: UNABLE TO REMOVE PREVIOUS TARGET
Cause: This error is generated when the .AOF (or .AOX) file cannot be removed. This file may
be already used or is set as read only.
Resolution: Check that nobody already uses it or that is not set as read only.
- 103 - F
16. Conformity LX51
16. Conformity
ROHS Compliance (Restriction of Hazardous Substances)
Raisonance products are certified to comply with the European Union RoHS Directive (2002/95/EC)
which restricts the use of six hazardous chemicals in its products for the protection of human health
and the environment.
The restricted substances are as follows: lead, mercury, cadmium, hexavalent chromium,
polybrominated biphenyls (PBB), and polybrominated diphenyl ethers (PBDE).
CE Compliance (Conformité Européenne)
Raisonance products are certified to comply with the European Union CE Directive.
In a domestic environment, the user is responsible for taking protective measures from possible radio
interference the products may cause.
FCC Compliance (Federal Communications Commission)

Raisonance products are certified as Class A products in compliance with the American FCC
requirements. In a domestic environment, the user is responsible for taking protective measures from
possible radio interference the products may cause.
WEEE Compliance (The Waste Electrical & Electronic Equipment Directive)
Raisonance disposes of its electrical equipment according to the WEEE Directive (2002/96/EC).
Upon request, Raisonance can recycle customer’s redundant products.
For more information on conformity and recycling, please visit the Raisonance website
www.raisonance.com
- 104 -
LX51 17. Glossary
17. Glossary
Term Description
CodeCompressor Post link code optimization tool
I/O Input/Output
ICC In-Circuit Communication
Ride7 Raisonance Integrated Development Environment
RLink Hardware tool for in-circuit debugging and programming of a target microcontroller
mounted on an application board. Supports interface via JTAG, ICC and SWIM
protocols.
SWIM Serial Wire Interface module
- 105 - F
18. Index LX51
18. Index
Alphabetical Index
ABSOLUTECODEOFFS...................................42 NOBRIDGE (NOBR).........................................65
Access functions...............................................55 NOCASESENSITIVITY (NOCS)........................64
AMAKE (AM).....................................................65 NODEBUGLINES (NODL)................................64
BANK (BA)........................................................65 NODEBUGPUBLICS (NODP)...........................64
Bank switches...................................................55 NODEBUGSYMBOLS (NODS).........................64
BANKAREA (BANKAREA)................................65 NODEFAULTLIBRARY (NLIB)..........................64
BANKMAX (BANKMAX)....................................65 NOFCTPTRMANAG.........................................47
BANKMIN (BANKMIN)......................................65 NOFCTPTRMANAG (NOFPM).........................63
BANKMODE (BM).............................................65 NOIXREF (NOIX)..............................................64
Baud rate...........................................................62 NOLINES (NOLI)...............................................64
BIT (BI)..............................................................63 NOMAP (NOMA)...............................................64
Bridges..............................................................54 NOOVERLAY (NOOL)......................................63
CASESENSITIVITY (CS)..................................64 NOPRINT (NOPR)............................................64
CE...................................................................104 NOPUBLICS (NOPU)........................................64
CODE (CO).......................................................63 NOSTATVARROM (NOSTATVARROM)..........65
CODESIZE (CSIZE)..........................................63 NOSYMBOLS (NOSB)......................................64
Compliance.....................................................104 Optimum memory usage...................................55
Conformity.......................................................104 Optimum performance......................................55
DATA (DT)........................................................63 OVERLAY.........................................................47
DEBUGLINES (DL)...........................................64 OVERLAY (OL).................................................63
DEBUGPUBLICS (DP)......................................64 PAGE (PA)........................................................63
DEBUGSYMBOLS (DS)....................................64 PDATA (PD)......................................................63
Directive..........................................................104 POSTOPTI (POSTOPTI)..................................64
FCC.................................................................104 PRECEDE (PC).................................................63
FLASH (FLS).....................................................65 PRINT (PR).......................................................64
FLASHBANKAREA (FLSBANKAREA)..............65 PUBLICS (PU)...................................................64
FLASHNAME (FLN)..........................................65 Raisonance ....................................................104
GLOBAL (GLB).................................................65 RAMSIZE (RS)..................................................63
IDATA (ID).........................................................63 RAMSIZEINIT (RSI)..........................................63
Increase code memory to 4Mb..........................49 Reduce RAM requirement.................................43
Initialize internal RAM........................................61 REFLASH (REFLS)...........................................65
INPAGE (IP)......................................................63 RESERVE (RES)..............................................65
ISR execution time............................................55 ROHS..............................................................104
IXREF (IX).........................................................64 SEGMENTOVERLAY (OS)...............................63
L51_BANK.A51.................................................52 STACK (ST)......................................................63
Large Look-up tables.........................................55 STARTCODE (STCO).......................................63
Lead................................................................104 STATVARROM (STATVARROM).....................65
LINES (LI).........................................................64 SYMBOLS (SB).................................................64
MAP (MA)..........................................................64 TO (TO).............................................................64
MEMORYOFFSET (MO)...................................63 Web site..............................................................8
MOVEABSCODE..............................................42 WEEE.............................................................104
MOVEABSCODE (MAC)...................................63 XDATA (XD)......................................................63
NAME................................................................20 XDATASIZE (XSIZE).........................................63
NAME (NA).......................................................64 -C64
NOAMAKE (NOAM)..........................................65 -VN....................................................................63
NOBRIDGE.......................................................55 ?BANK?SWITCH..............................................54
- 106 -
LX51 19. History
19. History
Date Modification
09 Mar 2010 Initial version for Ride7.
Disclaimer
Information in this document is subject to change without notice and does not represent a commitment
on the part of the manufacturer. The software described in this document is provided under license and
may only be used or copied in accordance with the terms of the agreement. It is illegal to copy the
software onto any medium, except as specifically allowed in the license or non disclosure agreement.
No part of this manual may be reproduced or transmitted in any form or by any means, electronic or
mechanical, including photocopying, recording, or information storage and retrieval systems, for any
purpose other than the purchaser’s personal use, without prior written permission.
Every effort has been made to ensure the accuracy of this manual and to give appropriate credit to
persons, companies and trademarks referenced herein.
This manual exists both in paper and electronic form (pdf).
Please check the printed version against the .pdf installed on the computer in the installation directory,
for the most up-to-date version.
The examples of code used in this document are for illustration purposes only and accuracy is not
guaranteed. Please check the code before use.
Copyright © Raisonance 1987-2010 All rights reserved
- 107 - F

LX51

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

LX51

Uploaded by

Copyright:

Available Formats

LX51

Code Banking Linker/Locator

3. Modules and segments....................................................................................................16

10. Initialization, buffers and stacks.....................................................................................61

11. Appendix A. Directives reference..................................................................................63

11.39 NODEBUGPUBLICS (NODP) ...................................................................................................78

12. Appendix B. Ride7 Linker options reference.................................................................88

12.1.6 Addition options....................................................................................................................90

13. Appendix C. Warning messages...................................................................................91

14. Appendix D. Error messages.........................................................................................94

15. Appendix E. Fatal error messages..............................................................................100

1.1 Purpose of this manual

1.2 Scope of this manual

1.3 Conventions used in this manual

1.4 Additional help or information

2.4 How the linker relates to other tools

.obj file .obj file

Linker Library Manager

2.5 Invoking and controlling the linker

***FATAL ERROR 203: EXPECTED ITEM MISSING

2.5.2 Ride7 (Raisonance Integrated Development Environment)

2.5.3 Command line syntax

2.6 Input files

2.6.1 Object files

2.6.2 Library files

2.7 Output files

2.7.1 Absolute object file

2.7.2 Map file (Linker listing file)

2.7.3 Cross-reference file

3. Modules and segments

Source File .c file

Segment Segment .obj

The data contained inside the module consists of:

3.1.1 Symbol table

s. . . . . . . . . . . . . . . STATIC DATA U_CHAR 0000H 1

3.1.2 Debugging information

3.3 Segment naming conventions

Where memoryspace is one of:

3.4 Output module

.obj .obj .lib

3.4.1 Symbol table

Map file item Map file description

4.2 Memory model

4.3 Input modules

<memory model> Library for

4.4 Link map

LINK MAP OF MODULE: C:\TEMP\TESTPROJECT\PROJECT.AOF (MAIN2)

TYPE BASE LENGTH RELOCATION SEGMENT NAME

Each line contains information about a single segment or contains a gap.

4.4.1 Link map information

The following is a description of each piece of information contained in a single line.

4.4.2 Uses for the Link map

4.4.4 PDATA and the external stack

4.4.5 Link map title information

4.4.6 Link map examples

Link map Example 1

TYPE BASE LENGTH RELOCATION SEGMENT NAME

Link map Example 2

TYPE BASE LENGTH RELOCATION SEGMENT NAME

Link map Example 3

TYPE BASE LENGTH RELOCATION SEGMENT NAME

Link map Example 4

TYPE BASE LENGTH RELOCATION SEGMENT NAME

4.5 Executable summary