ARM Technical Support Knowledge Articles


Applies to: BL51 Code-banking Linker/Locator


Information in this article applies to:


When changing the order in which object modules are linked, sometimes the generated application works and sometimes it fails.


There are a number of things that could cause this problem:

File Dependencies

If you use in-line assembly, it is very important to compile the .C files before any .SRC files. The .C files with in-line assembly generate the .SRC files. The .SRC files depend on the .C files.

If you compile the .SRC file first (the old one), then compile the .C file (with changes), the compiler generates a new .SRC file (but the old copy is the one that is compiled and linked).

To resolve this kind of problem, make sure the order of .C and .SRC files is correct.

Memory Corruption

A source file may include a function that uses memory it doesn't own. Indexing off the end of an array is just one example of this kind of problem. For example:

unsigned char array[10];
array[10] = 0xFF;  // Illegal because array has only
                   // 10 elements array[0]-array[9]

Changing the order in which files are linked locates an important data item after array. And, this item gets overwritten.

To resolve this kind of problem, you must analyze which files were modev to cause the problem. Then, look at those files and the ones before and after them in the link order. It may be worthwhile to use a utility like PC-Lint to verify your C code.

STARTUP Code Issues

The STARTUP code (and initialization code for real-time kernels) must be included at the end of the linker module list.

To resolve this kind of problem, make sure the STARTUP code is linked last.


Article last edited on: 2004-05-31 11:14:14

Rate this article

Disagree? Move your mouse over the bar and click

Did you find this article helpful? Yes No

How can we improve this article?

Link to this article
Copyright © 2011 ARM Limited. All rights reserved. External (Open), Non-Confidential