_DataEnd = . ;
} >rom
bss : /* Uninitialized data. */
{
_BssStart = . ;
*(.bss)
_BssEnd = . ;
}
_BottomOfHeap = . ; /* The heap starts here. */
_TopOfStack = 0x80000; /* The stack ends here. */
text rom : /* The actual instructions. */
{
*(.text)
}
}
This script informs the GNU linker's built-in locator about the memory on the
target board and instructs it to locate the data and bss sections in RAM (starting
at address 0x00000) and the text section in ROM (starting at 0x80000).
However, the initial values of the variables in the data segment will be made a
part of the ROM image by the addition of >rom at the end of that section's
definition.
All of the names that begin with underscores (_TopOfStack, for example) are
variables that can be referenced from within your source code. The linker will use
these symbols to resolve references in the input object files. So, for example, there
might be a part of the embedded software (usually within the startup code) that
copies the initial values of the initialized variables from ROM to the data section
in RAM. The start and stop addresses for this operation can be established
symbolically, by referring to the integer variables _DataStart and _DataEnd .
The result of this final step of the build process is an absolutely located binary
image that can be downloaded to the embedded system or programmed into a read-
only memory device. In the previous example, this memory image would be

exactly 1 MB in size. However, because the initial values for the initialized data
section are stored in ROM, the lower 512 kilobytes of this image will contain only
zeros, so only the upper half of this image is significant. You'll see how to
download and execute such memory images in the next chapter.
3.5 Building das Blinkenlights
Unfortunately, because we're using the Arcom board as our reference platform, we
won't be able to use the GNU tools to build the examples. Instead we'll be using
Borland's C++ Compiler and Turbo Assembler. These tools can be run on any
DOS or Windows-based PC.
[3]
If you have an Arcom board to experiment with,
this would be a good time to set it up and install the Borland development tools on
your host computer. (See Appendix A for ordering information). I used version 3.1
of the compiler, running on a Windows 95-based PC. However, any version of the
Borland tools that can produce code for the 80186 processor will do.
As I have implemented it, the Blinking LED example consists of three source
modules: led.c, blink.c, and startup.asm. The first step in the build process is to
compile these two files. The command-line options we'll need are -c for "compile,
but don't link," -v for "include symbolic debugging information in the output," -ml
for "use the large memory model," and -1 for "the target is an 80186 processor."
Here are the actual commands:
bcc -c -v -ml -1 led.c
bcc -c -v -ml -1 blink.c
Of course, these commands will work only if the bcc.exe program is in your PATH
and the two source files are in the current directory. In other words, you should be
in the Chapter2 subdirectory. The result of each of these commands is the creation
of an object file that has the same prefix as the .c file and the extension .obj. So if
all goes well, there will now be two additional files—led.obj and blink.obj —in the
working directory.
Although it would appear that there are only these two object files to be linked

together in our example, there are actually three. That's because we must also
include some startup code for the C program. (See Startup Code earlier in this
chapter.) Example startup code for the Arcom board is provided in the file
startup.asm, which is included in the Chapter3 subdirectory. To assemble this code
into an object file, change to that directory and issue the following command:
tasm /mx startup.asm
The result should be the file startup.obj in that directory. The command that's
actually used to link the three object files together is shown here. Beware that the
order of the object files on the command line does matter in this case: the startup
code must be placed first for proper linkage.
tlink /m /v /s \Chapter3\startup.obj led.obj blink.obj,
blink.exe, blink.map
As a result of the tlink command, Borland's Turbo Linker will produce two new
files: blink.exe and blink.map in the working directory. The first file contains the
relocatable program and the second contains a human-readable program map. If
you have never seen such a map file before, be sure to take a look at this one
before reading on. It provides information similar to the contents of the linker
script described earlier. However, these are results and, therefore, include the
lengths of the sections and the names and locations of the public symbols found in
the relocatable program.
One more tool must be used to make the Blinking LED program executable: a
locator. The locating tool we'll be using is provided by Arcom, as part of the
SourceVIEW development and debugging package included with the board.
Because this tool is designed for this one particular embedded platform, it does not
have as many options as a more general locator.
[4]

In fact, there are just three parameters: the name of the relocatable binary image,
the starting address of the ROM (in hexadecimal) and the total size of the
destination RAM (in kilobytes):

tcrom blink.exe C000 128
SourceVIEW Borland C ROM Relocator v1.06
Copyright (c) Arcom Control Systems Ltd 1994
Relocating code to ROM segment C000H, data to RAM segment 100H
Changing target RAM size to 128 Kbytes
Opening 'blink.exe'
Startup stack at 0102:0402
PSP Program size 550H bytes (2K)
Target RAM size 20000H bytes (128K)
Target data size 20H bytes (1K)
Creating 'blink.rom'
ROM image size 550H bytes (2K)
The tcrom locator massages the contents of the relocatable input file—assigning
base addresses to each section—and outputs the file blink.rom. This file contains
an absolutely located binary image that is ready to be loaded directly into ROM.
But rather than load it into the ROM with a device programmer, we'll create a
special ASCII version of the binary image that can be downloaded to the ROM
over a serial port. For this we will use a utility provided by Arcom, called bin2hex.
Here is the syntax of the command:
bin2hex blink.rom /A=1000
This extra step creates a new file, called blink.hex, that contains exactly the same
information as blink.rom, but in an ASCII representation called Intel Hex Format.
[1] Used this way, the term "target platform" is best understood to include not only
the hardware but also the operating system that forms the basic runtime
environment for your software. If no operating system is present—as is sometimes
the case in an embedded system—the target platform is simply the processor on
which your program will be run.
[2] Beware that I am only talking about static linking here. In non-embedded
environments, dynamic linking of libraries is very common. In that case, the code
and data associated with the library routine are not inserted into the program

directly.
[3] It is interesting to note that Borland's C++ compiler was not specifically
designed for use by embedded software developers. It was instead designed to
produce DOS and Windows-based programs for PCs that had 80x86 processors.
However, the inclusion of certain command-line options allows us to specify a
particular 80x86 processor—the 80186, for example—and, thus, use this tool as a
cross-compiler for embedded systems like the Arcom board.
[4] However, being free, it is also a lot cheaper than a more general locator.
Chapter 4. Downloading and Debugging
 4.1 When in ROM
 4.2 Remote Debuggers
 4.3 Emulators
 4.4 Simulators and Other Tools
I can remember the exact instant when I realized that a large part of my life from
then on was going to be spent in finding mistakes in my own programs.
—Maurice Wilkes, Head of the Computer Laboratory of the University of
Cambridge, 1949
Once you have an executable binary image stored as a file on the host computer,
you will need a way to download that image to the embedded system and execute
it. The executable binary image is usually loaded into a memory device on the
target board and executed from there. And if you have the right tools at your
disposal, it will be possible to set breakpoints in the program or to observe its
execution in less intrusive ways. This chapter describes various techniques for
downloading, executing, and debugging embedded software.
4.1 When in ROM
One of the most obvious ways to download your embedded software is to load the
binary image into a read-only memory device and insert that chip into a socket on
the target board. Obviously, the contents of a truly read-only memory device could
not be overwritten. However, as you'll see in Chapter 6, embedded systems
commonly employ special read-only memory devices that can be programmed (or

reprogrammed) with the help of a special piece of equipment called a device
programmer. A device programmer is a computer system that has several memory
sockets on the top—of varying shapes and sizes—and is capable of programming
memory devices of all sorts.
In an ideal development scenario, the device programmer would be connected to
the same network as the host computer. That way, files that contain executable
binary images could be easily transferred to it for ROM programming. After the
binary image has been transferred to the device programmer, the memory chip is
placed into the appropriately sized and shaped socket and the device type is
selected from an on-screen menu. The actual device programming process can take
anywhere from a few seconds to several minutes, depending on the size of the
binary image and the type of memory device you are using.
After you program the ROM, it is ready to be inserted into its socket on the board.
Of course, this shouldn't be done while the embedded system is still powered on.
The power should be turned off and then reapplied only after the chip has been
carefully inserted.
As soon as power is applied to it, the processor will begin to fetch and execute the
code that is stored inside the ROM. However, beware that each type of processor
has its own rules about the location of its first instruction. For example, when the
Intel 80188EB processor is reset, it begins by fetching and executing whatever is
stored at physical address FFFF0h. This is called the reset address, and the
instructions located there are collectively known as the reset code.