Motorola MVME162 Manuale Utente

Pagina di 136
Entering and Debugging Programs
MVME162IG/D2
4-9
4
Entering and Debugging Programs
There are various ways to enter a user program into system memory for 
execution. One way is to create the program using the Memory Modify (MM
command with the assembler/disassembler option. You enter the program 
one source line at a time. After each source line is entered, it is assembled and 
the object code is loaded to memory. Refer to the Debugging Package for 
Motorola 68K CISC CPUs User’s Manual
 for complete details of the 162Bug 
Assembler/Disassembler.
Another way to enter a program is to download an object file from a host 
system. The program must be in S-record format (described in the Debugging 
Package for Motorola 68K CISC CPUs User’s Manual
) and may have been 
assembled or compiled on the host system. Alternately, the program may have 
been previously created using the 162Bug MM command as outlined above 
and stored to the host using the Dump (DU) command. A communication link 
must exist between the host system and the MVME162 port 1. (Hardware 
configuration details are in the section on Installation and Startup in Chapter 3.) 
The file is downloaded from the host to MVME162 memory by the Load (LO
command.
Another way is by reading in the program from disk, using one of the disk 
commands (BOBHIOP). Once the object code has been loaded into memory, 
you can set breakpoints if desired and run the code or trace through it.
Calling System Utilities from User Programs
A convenient way of doing character input/output and many other useful 
operations has been provided so that you do not have to write these routines 
into the target code. You can access various 162Bug routines via one of the 
MC68040 TRAP instructions, using vector #15. Refer to the Debugging Package 
for Motorola 68K CISC CPUs User’s Manual
 for details on the various TRAP #15 
utilities available and how to invoke them from within a user program.
Preserving the Debugger Operating Environment
This section explains how to avoid contaminating the operating environment 
of the debugger. 162Bug uses certain of the MVME162 onboard resources and 
also offboard system memory to contain temporary variables, exception 
vectors, etc. If you disturb resources upon which 162Bug depends, then the 
debugger may function unreliably or not at all.