DEBUG MONITOR DESCRIPTION
M68CPU32BUG/D REV 1
2-7
2.2.2 Port Numbers
Some CPU32Bug commands allow the user to decide which port is the input or output port.
Valid port numbers are:
0 - MCU SCI Port
(RS-232C communication port; P4 on the BCC and P9 on the PFB)
Although CPU32Bug supports other ports (see PF command), there is no hardware present on
the BCC to support additional ports. Thus the commands which allow port numbers (DU, LO,
PF, VE) can only use port 0. Those commands requiring a second port (PA, TM) are not
functional without additional hardware.
2.3 ENTERING AND DEBUGGING PROGRAMS
There are various ways to enter a user program into system memory. One is to create the program
using the assembler/disassembler option and the MM (memory modify) command.
The user enters the program one source line at a time. After each source line is entered, it is
assembled and the object code is loaded into memory. Refer to Chapter 4 for complete details of
the CPU32Bug assembler/disassembler.
Another way to enter a program is to download an object file from a host system (i.e., a personal
computer). The program must be in S-record format (described in Appendix A) and may be
assembled or compiled on the host system. The file is downloaded from the host into BCC
memory via the debugger LO command. Alternately, the program may be created using the
CPU32Bug MM command as outlined above and stored to the host using the DU (dump)
command. A communication link must exist between the host system and the BCC’s serial port.
2.4 CALLING SYSTEM UTILITIES FROM USER PROGRAMS
A convenient method to input and output characters as well as many other useful operations is
provided by the TRAP #15 instructions. This frees the user from having to write these routines
into the target code. Refer to Chapter 5 for details on various TRAP #15 utilities and how to
execute them from a user program.
2.5 PRESERVING DEBUGGER OPERATING ENVIRONMENT
Avoiding contamination of the debugger operating environment is explained in the following
paragraphs. CPU32Bug uses certain MCU on-board resources and may also use off-board system
memory to store temporary variables, exception vectors, etc. If the user violates CPU32Bug
dependent memory space, then the debugger may not function.