Application Note GCC Compiler for Cortex-M3 How to ... - Hitex

Hitex Germany 

– Head Quarters – 

Greschbachstr. 12 

76229 Karlsruhe 

Germany 

� +049-721-9628-0 

Fax +049-721-9628-149 

E-mail: Sales@hitex.de 

WEB: www.hitex.de 

Hitex UK 

Warwick University 

Science Park 

Coventry CV47EZ 

United Kingdom 

� +44-24-7669-2066 

Fax +44-24-7669-2131 

E-mail: Info@hitex.co.uk 

WEB: www.hitex.co.uk 

Application Note 

Hitex USA 

2062 Business Center Drive 

Suite 230 

Irvine, CA 92612 

U.S.A. 

� 800-45-HITEX (US only) 

� +1-949-863-0320 

Fax +1-949-863-0331 

E-mail: Info@hitex.com 

WEB: www.hitex.com 

GCC Compiler for Cortex-M3 

How to optimize V4.4.0 Settings 

This documentation demonstrates how to use and 

optimize the GCC compiler settings for Cortex-M3 

(Thumb2) code generation including detailed 

examples on 'eh-frame', 'stubs' and 'vectors'. 

Architecture: ARM/Cortex 

Author: Stefan Grohmann / Hitex Germany 

Revision: 10/2009 - 001 

© Copyright 2009 - Hitex Development Tools GmbH 

All rights reserved. No part of this document may be copied or reproduced in any form or by any means without prior written consent of Hitex Development Tools. Hitex Development Tools retains 

the right to make changes to these specifications at any time, without notice. Hitex Development Tools makes no commitment to update nor to keep current the information contained in this 

document. Hitex Development Tools makes no warranty of any kind with regard to this material, including, but not limited to, the implied warranties of merchantability and fitness for a particular 

purpose. Hitex Development Tools assumes no responsibility for any errors that may appear in this document. DProbe, Hitex, HiTOP, Tanto, and Tantino are trademarks of Hitex Development 

Tools. All trademarks of other companies used in this document refer exclusively to the products of these companies. 

ApplicationNote.dot - 11/2007 - 005


Preface 

In order to keep you up-to-date with the latest developments on our products, we provide Application 

Notes containing additional topics, special hints, examples and detailed procedures etc. 

For more information on the current software and hardware revisions, as well as our update service, 

please visit www.hitex.de, www.hitex.co.uk or www.hitex.com. 

Contents 

1 What is the Motivation? 3 

1.1 Error Occurrences 3 

2 Compiler Settings for Cortex-M3 Derivatives 4 

2.1 Assembler Parameters 4 

2.2 Assembler Code 5 

2.3 C Compiler Parameters 6 

2.4 C Code 7 

2.5 Linker Parameters 8 

2.6 Linker Description File (ld File) 9 

3 Conclusion 12 

© Copyright 2009 Hitex Development Tools GmbH Page 2/12


1 What is the Motivation? 

The usage of the GCC compiler for ARM/Cortex version 4.4.0 provided by Hitex is a complex issue 

and sometimes not quite easy to handle for the user. Some settings may result in erroneous outputs of 

the compiler or linker when used for different target platforms. 

This document is intended to give support to the users on how to set and optimize some common 

parameters. 

The following code segments and settings are to be used with the HiTOP development environment 

and the current GNU C compiler version 4.4.0. 

The examples in chapter Compiler Settings for Cortex-M3 Derivatives are chosen to give an overview 

and to enable the user to have a complete bunch of settings for a successful start of projects. 

Note that all examples are only usable for Cortex-M3 target devices. 

For further information on options for the compiler and linker, please have a look at the GCC web 

references, e.g. http://gcc.gnu.org/onlinedocs. 

To learn more about the HiTOP environment and compiler settings in the IDE, refer to the help system 

installed with HiTOP. 

1.1 Error Occurrences 

Errors occurring when compiling or using the debugger to single step compiled code are mostly the 

result of using wrong parameters ('options') for the compiler and linker. 

These options are set in the HiTOP environment related to complete projects or single files, and often 

a separate file with additional options for the linker is used. 

The main error behavior is: 

(1) Debug information can not be used or is not bound to files and their code. In disassembly view, 

the modules are mixed up and in the module view empty labels are visible. 

(2) The linker terminates with an error 

overlapping section .data 

In both cases, the following sections should be read with attention. 



2 Compiler Settings for Cortex-M3 Derivatives 

The common settings of the compiler call in the HiTOP environment are divided into 

• assembler-related 

• C-compiler-related 

• linker-related 

call parameters which will be covered in the following. 

2.1 Assembler Parameters 

In general, the assembler is running fine with the following options: 

-mcpu=cortex-m3 -gdwarf2 –mthumb 

-mcpu=cortex-m3 Specifies the core architecture used. 

The alternative –marm[vx] is not applicable. 

-gdwarf2 Specifies the debug information output. 

Useful if you want to debug the code. 

-mthumb Specifies the code generation. 

It should be applied even if the architecture only specifies the Thumb2 

instruction set. 



2.2 Assembler Code 

Specific entries must be set in the assembler code: 

.text 

; /* to specify that code is following */ 

.syntax unified 

.global _MyASMRoutine 

… 

.type _ MyASMRoutine, function 

.equ pattern1, 0xAAAAAAAA 

; /*.bit pattern */ 

.thumb 

; /* this causes thumb code generation */ 

_ MyASMRoutine: 

; /* Push ALL registers to stack */ 

Push {r0-r12,r14} 

; /* some instructions */ 

movw r0, #0x00AA 

cmp r0, #0xAA 

bne _ exitLabel 

; /* some more instructions */ 

movw r0, #0xAA00 

lsr r0, #8 

cmp r0, #0xAA 

bne _ exitLabel 

_exitLabel: 

; /* Pop the stack back */ 

pop {r0-r12,r14} 

; /* Branch back */ 

bx lr 

.end 

If the functions are called from a C file without taking care of the architecture, the code may produce 

warnings with the linker, e.g. that "ARM calls" are enabled or that the "thumb-interworking" is not 

enabled. 

This behavior occurs because of the addressing method used by the C compiler according to the 

Cortex-M3 architecture. 

Normally, the C compiler does not produce any long calls so that the addressing is limited. In other 

ARM architectures this is fixed by using the thumb-interworking to enable the compiler to build long 

veneers. 



2.3 C Compiler Parameters 

-c -gdwarf-2 -MD -O0 -trigraphs -mcpu=cortex-m3 -mthumb -Wall -fsigned-char -mlittle-endian 

-xc -mno-thumb-interwork -mno-tpcs-frame -mlong-calls 

-c Compiles or assembles the source files, but does not link. 

-gdwarf-2 Produces debugging information in DWARF version 2 format. 

-MD The compiler generates intermediate files with the suffix '.d'. 

-O0 Do not optimize (best for debugging). 

-trigraphs Supports ISO C trigraphs. 

-mcpu=cortex-m3 Specifies the core architecture used. 

-mthumb Specifies the code generation. This option should be applied even if 

the architecture only specifies the Thumb2 instruction set. 

-Wall Prints all warnings. 

-fsigned-char Lets the type char be signed, like signed char. 

-mlittle-endian Generates code for a processor running in 'Little Endian' mode. 

-xc Specifies the source language; here: C 

-mno-thumb-interwork Does not use the interworking. 

-mno-tpcs-frame Generates no stack frame that is compliant with the Thumb Procedure 

Call Standard for all non-leaf functions. 

-mlong-calls Tells the compiler to perform function calls by first loading the address 

of the function into a register and then performing a subroutine call on 

this register. *) 

*) This parameter is used to generate a call over the whole address area which solves the problem to call the assembler 

routines. 



2.4 C Code 

Normally, the C code does not include any arguments for the linker or compiler. This will generate 

sections information for the sections ".text", ".data" and ".bss". If modules or variables are intended to 

be treated in a special way, the code must include this information. 

Using Linker-Generated Address Labels 

extern unsigned long _etext; 

extern unsigned long _data; 

extern unsigned long _edata; 

extern unsigned long _bss; 

extern unsigned long _ebss; 

extern unsigned long _stacktop; 

The labels are available for usage in the code. The label "_stacktop" is defined in the linker file and 

defines the upper end of the stack area in the SRAM of the device. The label will be filled by the linker. 

All other labels are also generated by the linker and provide information on the SRAM usage. 

Placing Constant Data to a Specified Location 

typedef void (* const FuncPointer)(void); 

A type "FuncPointer" is defined and a table of entries is generated which builds the vector table of a 

Cortex-M3 controller. This table must be located at the address 0x0000 0000 on each Cortex-M3 

controller. 

The address is well-known but the linker must be informed about the way to handle this. The section 

".vectors" which is defined here, is used by the linker file to specify the placement (see section Linker 

Description File). 

void Reset(void); 

FuncPointer interrupts[] __attribute__ ((section(".vectors"))) = 

{ 

(IntFctPointer)&_stacktop, // The initial stack pointer (see above) 

Reset, // first vector to Reset routine 

… 

Copying the Initialized Data 

unsigned long *Src, *Dest; 

The pointers defined are used to simply copy the ".data" section to the SRAM at the start of the 

application. 

// Initialize data 

// Copy the data segment initializers from flash to SRAM. 

Src = &_etext; 

for(Dest = &_data; Dest < &_edata; ) 

{ 

*Dest++ = *Src++; 

} 



Clearing the Uninitialized Data 

When deleting the uninitialized SRAM segment, the start and end must be known. The linker can 

provide this information. 

// Zero fill the bss segment. 

for(Dest = &_bss; Dest < &_ebss; ) 

{ 

*Dest++ = 0; 

} 

In this case, the application must be called from here: 

// Call main. 

main(); 

2.5 Linker Parameters 

The linker can be called with the following options: 

--cref -t -static -nostartfiles -Map=.\objects\main.map -stats -lc -lgcc 

--cref Does not output a cross reference table to the map file. 

-t Traces linked files. 

-static On systems supporting dynamic linking, this prevents linking with 

the shared libraries. 

-nostartfiles Does not use the standard system startup files when linking. 

-Map=.\objects\main.map Generates a map file. 

-stats Displays statistical outputs. 

-lc Uses the C library. 

-lgcc Uses the GCC library. 

In addition, HiTOP inserts the linker file option (-T[file]) to the calling options. The linker file describes 

further code segmentation and memory usage. 



2.6 Linker Description File (ld File) 

To enable the linker to take care of the derivative-specific memory layout and passing the code 

optimally into the Flash and RAM segments, the linker has to know about this. 

Adding libraries to the linker is always in conjunction with the knowledge of their location. The linker 

must be referenced to the locations. 

Due to the variety of the current GCC versions, the path must be adjusted to the used version: 

SEARCH_DIR( "$(ToolDir)\..\arm-hitex-elf\lib\thumb2" ) 

/* Path setting depends on the gnu compiler version */ 

… or all possible paths must be entered as follows: 

SEARCH_DIR("$(ToolDir)\..\lib\gcc\arm-hitex-elf\4.3.0\thumb\thumb2" ) 



SEARCH_DIR("$(ToolDir)\..\lib\gcc\arm-hitex-elf\4.4.0\thumb2" ) 

SEARCH_DIR("$(ToolDir)\..\lib\gcc\arm-hitex-elf\$(GNU_CORTEX_VERSION)\thumb2" ) 

The input is specified either by the file names or byte list which is generated by HiTOP: 

INPUT ( 

/* HiTOP will automatically put in here all object files to be linked. 

Leave this unchanged! */ 

$(LinkObjects) 

) 

The target-specific parameters contain information about the physical memory layout of the target 

derivative: 

/* Target Specific Parameters */ 

MEMORY 

{ 

FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 0x80000 

SRAM (rwx) : ORIGIN = 0x10000000, LENGTH = 0x8000 

} 

Sections define physical opcode or data areas which are connected to specified or default code, 

constants or variables. In general the sections .text, .data and .bss are defined by default. 

Additional sections can be defined and located in the physical memory: 

/* Layout Information */ 

/* Section Definitions */ 

SECTIONS 

{ 

The first section is the .text section containing the startup code and all other opcode. The start 

address is the first address defined or zero: 

.text : 

{ 

KEEP(*(.vectors .vector.*)) 

The label vectors must be located at the very beginning and must not be changed (see section 

C Code). 



Next is the startup code and an address label is generated (_startup_code_end__): 

__startup_code__ = .; 

$(TargetDir)startup.o (.text) /* Startup code */ 

__startup_code_end__ = .; 

Then the rest of the code is put into the .text section and is aligned to 4 bytes: 

*(.text .text.*) 

*(.gnu.linkonce.t.*) 

*(.glue_7) 

*(.glue_7t) 

. = ALIGN(4); 

.Eh_frame is recommended to be placed by the linker: 

*(.rodata .rodata*) 

*(.gnu.linkonce.r.*) 

*(.eh_frame) 

. = ALIGN(4); 

With the address label _etext the .text section is completed and all is located in the physical memory 

area defined as "FLASH": 

_etext = .; 

} > FLASH 

The next section is defined as .data containing all the initializing data for the pre-initialized variables: 

.data : AT (_etext) 

{ 

Start the section at the end of the .text section to reside in the non-volatile memory. The startup code 

must copy this to the RAM before using any initialized variables. Add all segments defined as ".data": 

_data = .; 

*(.data .data.*) 

*(.gnu.linkonce.d*) 

The linker generates an address label edata and locates the heap with size 0x2000 followed by the 

stack: 

. = ALIGN(4); 

_edata = . ; 

/* HEAP!!! */ 

. = . + 0x2000; /* reserved for heap */ 

. = ALIGN(4); 

On the target segment (SRAM) at the very end, the _stacktop address is set to an absolute address 

of 0x8000-4: 

*(.stack .stack.*) 

. = ALIGN(4); 

_stacktop = 0x8000-4; /* Top of Stack */ 

The address model for SRAM space is used here: 

} > SRAM 



Uninitialized data are located in the .bss section. The section can be cleared by the startup code if it is 

located and the address labels are known in the code. 

An address label _bss is built and all elements are filled into this section: 

/* .bss section which is used for uninitialized data */ 

.bss (NOLOAD) : 

{ 

_bss = . ; 

Generate an address label _ebss: 

*(.bss .bss.*) 

*(.gnu.linkonce.b*) 

*(COMMON) 

. = ALIGN(4); 

_ebss = . ; 

} > SRAM 

Before ending the SECTION part of the linker file, the overall (natural) alignment of the device is 

specified to 4 byte: 

} 

. = ALIGN(4); 

_end = . ; 

PROVIDE (end = .); 



3 Conclusion 

The setup of linker and compiler is a complex issue and should be modified only by developers with 

expertise on GCC tools. 

In general, all necessary settings have been already made in the examples available for the 

corresponding HiTOP installation and templates. 

Hitex permanently updates its web sites with additional information and examples. 

So for the user it is an absolute must being updated regularly. 

Taking into account the fact that GNU compilers are under permanent development, the 

version and the changes of newer compilers should be carefully checked and evaluated 

before updating. 

© Copyright 2009 Hitex Development Tools GmbH Page 12/12 

�

Application Note GCC Compiler for Cortex-M3 How to ... - Hitex

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?