Motorola MVME712AM Installation guide Download

Entering and Debugging Programs
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
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)
Another way is by reading in the program from disk, using one of the disk
commands (BO, BH, IOP). 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.