The MSP430 Assembly Language Tools User's Guide explains how to use the following Texas Instruments Code Generation object file tools:
This book helps you learn how to use the Texas Instruments object file and assembly language tools designed specifically for the MSP430™ 16-bit devices. This book consists of four parts:
This document uses the following conventions:
special typeface
. Interactive
displays use a bold version of the special typeface to distinguish commands that you enter
from items that the system displays (such as prompts, command output, error messages,
etc.). Here is a sample of C code:
#include <stdio.h>
main()
{ printf("hello world\n");
}
cl430 [options] [filenames] [--run_linker [link_options] [object files]] |
cl430 --run_linker {--rom_model | --ram_model} filenames [--output_file=name.out] | |
--library=libraryname |
symbol .usect "section name", size in bytes[, alignment] |
.byteparameter1[, ... , parametern] |
Symbol | Definition |
---|---|
B,b | Suffix — binary integer |
H, h | Suffix — hexadecimal integer |
LSB | Least significant bit |
MSB | Most significant bit |
0x | Prefix — hexadecimal integer |
Q, q | Suffix — octal integer |
See the following resources for further information about the TI Code Generation Tools:
You can use the following books to supplement this user's guide:
MSP430™ is a trademark of Texas Instruments.
All trademarks are the property of their respective owners.
The MSP430™ is supported by a set of software development tools, which includes an optimizing C/C++ compiler, an assembler, a linker, and assorted utilities. This chapter provides an overview of these tools.
The MSP430 is supported by the following assembly language development tools:
This chapter shows how these tools fit into the general software tools development flow and gives a brief description of each tool. For convenience, it also summarizes the C/C++ compiler and debugging tools. For detailed information on the compiler and debugger, and for complete descriptions of the MSP430, refer to the books listed in Related Documentation From Texas Instruments.
Figure 2-1 shows the MSP430 software development flow. The shaded portion highlights the most common development path; the other portions are optional. The other portions are peripheral functions that enhance the development process.
The following list describes the tools that are shown in Figure 2-1:
In addition, the following utilities are provided to help examine or manage the content of a given object file:
The assembler creates object modules from assembly code, and the linker creates executable object files from object modules. These executable object files can be executed by an MSP430 device.
Object modules make modular programming easier because they encourage you to think in terms of blocks of code and data when you write an assembly language program. These blocks are known as sections. Both the assembler and the linker provide directives that allow you to create and manipulate sections.
This chapter focuses on the concept and use of sections in assembly language programs.
The object files created by the assembler and linker conform to the ELF (Executable and Linking Format) binary format, which is used by the Embedded Application Binary Interface (EABI). See the MSP430 Optimizing C/C++ Compiler User's Guide (SLAU132) and The MSP430 Embedded Application Binary Interface Application Report (SLAA534) for information on the EABI ABI.
COFF object files are not supported in v15.6.0.STS and later versions of the TI Code Generation Tools. If you would like to produce COFF output files, please use v4.4 of the MSP430 Code Generation Tools and refer to SLAU131J for documentation.
The ELF object files generated by the assembler and linker conform to the December 17, 2003 snapshot of the System V generic ABI (or gABI).
The linker produces executable object modules. An executable object module has the same format as object files that are used as linker input. The sections in an executable object module, however, have been combined and placed in target memory, and the relocations are all resolved.
To run a program, the data in the executable object module must be transferred, or loaded, into target system memory. See Chapter 4 for details about loading and running programs.
The smallest unit of an object file is a section. A section is a block of code or data that occupies contiguous space in the memory map. Each section of an object file is separate and distinct.
ELF format executable object files contain segments. An ELF segment is a meta-section. It represents a contiguous region of target memory. It is a collection of sections that have the same property, such as writeable or readable. An ELF loader needs the segment information, but does not need the section information. The ELF standard allows the linker to omit ELF section information entirely from the executable object file.
Object files usually contain three default sections:
.text section | Contains executable code (1) |
.data section | Usually contains initialized data |
.bss | Usually reserves space for uninitialized variables |
The assembler and linker allow you to create, name, and link other kinds of sections. The .text, .data, and .bss sections are archetypes for how sections are handled.
There are two basic types of sections:
Initialized sections | Contain data or code. The .text and .data sections are initialized; user-named sections created with the .sect and .intvec assembler directives are also initialized. |
Uninitialized sections | Reserve space in the memory map for uninitialized data. The .bss section is uninitialized; user-named sections created with the .usect assembler directive are also uninitialized. |
Several assembler directives allow you to associate various portions of code and data with the appropriate sections. The assembler builds these sections during the assembly process, creating an object file organized as shown in Figure 3-1.
One of the linker's functions is to relocate sections into the target system's memory map; this function is called placement. Because most systems contain several types of memory, using sections can help you use target memory more efficiently. All sections are independently relocatable; you can place any section into any allocated block of target memory. For example, you can define a section that contains an initialization routine and then allocate the routine in a portion of the memory map that contains ROM. For information on section placement, see the "Specifying Where to Allocate Sections in Memory" section of the MSP430 Optimizing C/C++ Compiler User's Guide.
Figure 3-1 shows the relationship between sections in an object file and a hypothetical target memory. ROM may be EEPROM, FLASH or some other type of physical memory in an actual system.
You can use the .sect and .usect directives to create any section name you like, but certain sections are treated in a special manner by the linker and the compiler's run-time support library. If you create a section with the same name as a special section, you should take care to follow the rules for that special section.
A few common special sections are:
For more information on sections, see the "Specifying Where to Allocate Sections in Memory" section of the MSP430 Optimizing C/C++ Compiler User's Guide.
The assembler identifies the portions of an assembly language program that belong in a given section. The assembler has the following directives that support this function:
The .bss and .usect directives create uninitialized sections; the .text, .data, and .sect directives create initialized sections.
You can create subsections of any section to give you tighter control of the memory map. Subsections are created using the .sect and .usect directives. Subsections are identified with the base section name and a subsection name separated by a colon; see Section 3.5.6.
If you do not use a section directive, the assembler assembles everything into the .text section.
Uninitialized sections reserve space in MSP430 memory; they are usually placed in RAM. These sections have no actual contents in the object file; they simply reserve memory. A program can use this space at run time for creating and storing variables.
Uninitialized data areas are built by using the following assembler directives.
Each time you invoke the .bss or .usect directive, the assembler reserves additional space in the .bss or the user-named section. The syntax is:
.bss symbol, size in bytes[, alignment ] | |
symbol | .usect "section name", size in bytes[, alignment ] |
symbol | points to the first byte reserved by this invocation of the .bss or .usect directive. The symbol corresponds to the name of the variable for which you are reserving space. It can be referenced by any other section and can also be declared as a global symbol (with the .global directive). |
size in bytes | is an absolute expression (see Section 5.10).
|
alignment | is an optional parameter. It specifies the minimum alignment in bytes required by the space allocated. The default value is byte aligned; this option is represented by the value 1. The value must be a power of 2. The maximum alignment is 32K. |
section name | specifies the user-named section in which to reserve space. See Section 3.5.3. |
Initialized section directives (.text, .data, .intvec, and .sect) change which section is considered the current section (see Section 3.5.4). However, the .bss and .usect directives do not change the current section; they simply escape from the current section temporarily. Immediately after a .bss or .usect directive, the assembler resumes assembling into whatever the current section was before the directive. The .bss and .usect directives can appear anywhere in an initialized section without affecting its contents. For an example, see Section 3.5.7.
The .usect directive can also be used to create uninitialized subsections. See Section 3.5.6 for more information on creating subsections.
The .common directive is similar to directives that create uninitialized data sections, except that common symbols are created by the linker instead.