As shipped, the arcom board includes a free debug monitor in Flash memory. Together with host software provided by Arcom, this debug monitor can be used to download programs directly into target RAM and execute them. To do this, you can use the tload utility. simply connect the sourceview serial communications adapter to the target and host as instructed in the "SourceVIEW for Target188EB User's Manual" and issue the following command on the host PC:
tload g blink.exe
SourceView Target Loader v1.4
Copyright (c) Arcom Control Systems Ltd 1994
Opening 'blink.exe' download size 750H bytes (2K)
Checking COM1 (press ESC key to exit)
Remote ident: TDR188EB version 1.02
Download successful
Sending 'GO' command to target system
The -g option tells the debug monitor to start executing the program as soon as the download is complete. So, this is the RAM equivalent of execution directly out of ROM. In this case, though, we want to start with the relocatable program. The tload utility will automatically locate the program for us, at the first available location in RAM.
For remote debugging purposes, Arcom's debug monitor can be used with Borland's Turbo Debugger as the frontend. turbo debugger can then be used to step through your C/C++ and assembly language programs, set breakpoints in them, and monitor variables, registers, and the stack as they execute.
Here's the command you would use to start a debugging session for the blinking led program:
tdr blink.exe
tver 3.1
Target Debugger Version Changer v1.2
Copyright (c) Arcom Control Systems Ltd 1994
Checking COM1 (press ESC key to exit)
Remote ident: TDR188EB version 1.02
TDR88 set for TD version 3.1
td rp1 rs3 blink.exe
Turbo Debugger Version 3.1
Copyright (c) 1988,92 Borland International
Waiting for handshake from remote driver (Ctrl-Break to quit)
The tdr command is actually a batch file that invokes two other commands. The first tells the on-board debug monitor which version of Turbo Debugger you will be using, and the second actually invokes it. Both of these commands need to be issued each time you want to start a remote debugging session with the Arcom board. The tdr.bat batch file exists solely to combine them into a single command line. Again we use the relocatable version of the program because we will be downloading the program into RAM and executing it from there.
The debugger startup options -rp1 and -rs3 establish the parameters for the communications link to the debug monitor. -rp1 means "remote-port=1" (COM1) and -rs3 means "remote-speed=3" (38,400 baud). These are the parameters required to communicate with Arcom's debug monitor. After establishing a connection to the debug monitor, Turbo Debugger should start running. If it does not, there might be a problem with the serial link. Compare your setup of the link to the one in the SourceVIEW user's manual.
Once you're in Turbo Debugger, you will see a dialog box that says: "Program out of date on remote, send over link?" When you select "Yes," the contents of the file blink.exe will be downloaded to the target RAM. The debugger will then set an initial breakpoint at main and instruct the debug monitor to execute the program until that point is reached. So the next thing you should see is the C source code for main , with a cursor indicating that the embedded processor's instruction pointer is at the entry point to that routine.
Using normal Turbo Debugger commands, you can step through the program, set breakpoints, monitor the values stored in variables and registers, and do all of the other things debuggers allow. Or you can simply press the F9 key to immediately execute the rest of the program. If you do this, you should then see the green LED on the
front of the board start blinking. When you are satisfied that the program and the debugger are both working properly, press the reset switch attached to the Arcom board. This will cause the embedded processor to be reset, the LED to stop blinking, and Turbo Debugger to again respond to your commands.
4.3 Emulators
Like a debug monitor, an emulator uses a remote debugger for its human interface. In some cases, it is even possible to use the same debugger frontend for both. But because the emulator has its own copy of the target processor it is possible to monitor and control the state of the processor in real time. This allows the emulator to support such powerful debugging features as hardware breakpoints and real-time tracing, in addition to the features provided by any debug monitor.
With a debug monitor, you can set breakpoints in your program. However, these software breakpoints are restricted to instruction fetches the equivalent of the command "stop execution if this instruction is about to be fetched." Emulators, by contrast, also support hardware breakpoints. Hardware breakpoints allow you to stop execution in response to a wide variety of events. These events include not only instruction fetches, but also memory and I/O reads and writes, and interrupts. For example, you might set a hardware breakpoint on the event "variable foo contains 15 and register AX becomes 0."