User guide

ManualsBrandsARM ManualsComputer HardwareVERSION 1.2

101

102

103

104

105

106

107

108

109

110

6.10 Troubleshooting

This section provides solutions to the following common problems:

• Linker error __semihosting_swi_guard

• Setting $top_of_memory

• Vector table code eliminated.

• Errors with scatter-loading description files.

6.10.1 Linker error __semihosting_swi_guard

The linker reports __semihosting_swi_guard as being multiply defined.

Cause

The linker loaded the semihosting implementation of a function from the ANSI C library. This error message is issued

if you have imported the semihosting guard symbol with #pragma import(__use_no_semihosting_swi), or

called the C guard function __use_no_semihosting_swi(), and have also called a library function that uses

semihosting.

Solution

This problem can be fixed in one of the following ways:

• Redefine the semihosted functions with your own implementation. The new functions are used instead of the C

library versions.

• If the semihosted functions are used only when building an application version of your ROM image for

debugging purposes, comment them out with an #ifdef when building a ROM image.

To locate the functions that use semihosting, link with -verbose -errors file.txt and search the output log

file for occurrences of __I_use_semihosting_swi.

6.10.2 Setting $top_of_memory

The debugger internal variable $top_of_memory tells the debugger where the highest writable address is in the

memory map of a remote target. By default, this address is used to place the stack and heap. The default value for

$top_of_memory is 0x80000.

Different boards might have different memory maps, so $top_of_memory must be changed to one plus the address

of the top of the RAM for your board. This must be done before running an application, otherwise you may

experience data aborts or code crashes.

For an unexpanded Integrator core module, set $top_of_memory to 0x40000.

If your board has extra DRAM modules fitted, you should change $top_of_memory appropriately.

$top_of_memory only applies to Multi-ICE and EmbeddedICE. It does not apply to Angel or ARMulator. (The top of

memory for Angel is hard-coded in the porting and the stackbase in ARMulator is determined by a config file.)

6.10.3 Vector table code eliminated

By default, the linker removes code sections that are never executed, or data that is never referred to, from the final

image. To see if any sections have been removed, link with the -info unused option.

Follow the steps below to ensure that the vector table is not inadvertently removed.

1. Mark all entry points with the assembler directive ENTRY. The C library has an entry point at __main().

2. Use the command-line option -entry to select one of the entry points as the image entry point. If a unique

entry point is not specified, the linker warns:

Image does not have an entry point. (Not specified or not set due to multiple choi

ces).

The recommended link options for embedded images are:

armlink obj1.o obj2.o -scatter scat.scf -info unused -entry 0x0 -o prog.axf

6.10.4 Errors with scatter-loading description files

If you encounter errors when you attempt to link using scatter-loading description file, try to simplify the build process

and gradually add more complexity. Some techniques that might be useful are listed below.

Writing Code for ROM