Tool Chain Flow
The Metrowerks CodeWarrior tool-chain is very similar to many others in that it uses a so-called relocatable assembler and compiler, along with a linker. The following figure outlines how the tools work together. The user enters so-called source files that are either assembled or compiled, producing object files. In addition to user supplied object code, most tool-chains provide additional libraries that can be used.
The linker follows directives provided by the user in the parameter file to organize the object files and contributions from the library files into a single executable image file. If your only experience with embedded microprocessors involves use of a so called absolute assembler, you will find this process to be more complicated than you are used to. In the long run, however there are benefits to this approach.
Lets contrast the idea of absolute assembly with that of relocatable assembly. An assembler performs absolute assembly, using the ORG directive which provides the start address of each block of memory. In this way it is known in advance, in the source code, what the actual addresses of code will be. For a short program with few files, written entirely in assembly language, this approach works. However, for larger programs written in a high level language, the use of the ORG directive is less desirable. We don't want to hand tweak so many files.
A relocatable assembler however, defers the assignment of addresses. In combining object files together, the linker is responsible for assigning actual addresses to code and data. With relocating tools you don't specify in your source code the actual addresses. Relocatable tools are useful for writing large programs for large computer systems, where you don't know in advance where code or data will end up. In such systems it is convenient to let the tools deal with such details.
The embedded systems we deal with have characteristics that suggest having absolute control of addressing at some times, and allowing the tools to relocate things at other times. The Metrowerks CodeWarrior tools support both absolute addressing in source code, as well as address relocation. This is done by requiring that regions of code or data, called sections be declared as either relocatable or absolute. In the end it is still the linker that positions all the memory sections.
The compiler and assembler organize your code into sections. Each section has a name, a type, and some attributes. The type is either absolute or relocatable. The section content attribute is assigned by what the section contains. The following outlines the sections types:
The Metrowerks assembler and linker allow a mix of absolute and relocatable sections. The main difference between absolute and relocatable sections involves the way the sections are placed in the system memory space. In using absolute sections, you are responsible for ensuring that no overlap exists between sections. In using a relocatable section, the linker does the job of assigning addresses according rules outlined in the parameter file.
In the project window click the Link Order tab and double click on default.prm. This is the parameter file which contains information that the linker uses to construct executable code. The file is divided into paragraphs and statements. The paragraphs are each opened by the keywords NAMES, SEGMENTS, and PLACEMENT, respectively. Each paragraph is closed with the keyword END. A paragraph is further divided into statements, each of which may end with a semicolon. The other lines in a parameter file are commands. The following is a parameter file written for a small program written entirely in assembly language.
The NAMES paragraph can be used to list object files used to construct the executable code, but generally is not used. Here the file names are passed as command line arguments when the linker is called for execution.
A SEGMENTS paragraph assigns meaningful names to contiguous memory areas of the target system and can describe a memory map. The segments are named MY_ROM, MY_RAM, and MY_STK. The key words READ_ONLY and READ_WRITE are related to whether or not the segments are to be initialized. Other key words such as NO_INIT and PAGED are appropriate for battery backed up RAM and paged memory systems, respectively.
There are cases where the SEGMENTS paragraph is different from the actual system memory map. In developing an application using RAM, time is saved by not having to reprogram FLASH. In addition, RAM better supports the use of break points.
The PLACEMENT block assigns sections to the named memory blocks. The sections named in a placement paragraph may be user defined, or may be linker-predefined sections. The linker is case sensitive, each section named here must be a valid predefined or user defined section.
The names .data, .text, and .stack are predefined by the linker to match sections that are of type data, code, and stack, respectively. The up-shot is that sections named in the source code can be, but are not required to be named in the parameter file placement paragraph. Such unspecified sections will be placed, based on type.
The line beginning with the keyword VECTOR is a command that assigns the address of the instruction at main to the reset vector, which is located at address $FFFE. In the source file it is important that the XDEF directive be used to declare main as public, otherwise the linker will not be able to find that symbol and thus won't be able to assign the reset vector. Finally, the keyword INIT defines the entry point which a simulator uses to start execution of the code.
The names DEFAULT_ROM and DEFAULT_RAM in the PLACEMENT paragraph are predefined and understood by the linker to place sections as required in the memory map. For more information than that presented here, refer to the SmartLinker manual.
This parameter file shows an alternative way to declare the stack size, here only the stack size is given. The VECTOR command here is similar to that above in that the linker associates vector number 0 with address 0xFFFE. In this example _Startup refers to a block of code that is executed before main() is called.
Written by Jonathan Hill (jmhill at hartford.edu)
Revised: Thu Feb 3 18:49:39 EST 2005