Motorola M68CPU32BUG Manuel d'utilisateur télécharger pdf (Page 5)

GENERAL INFORMATION

M68CPU32BUG/D REV 1 1-4

NOTE

In order for high-baud rate serial communication between

CPU32Bug and the terminal to function properly, the terminal

must use XON/XOFF handshaking. If messages are garbled and

have missing characters, check the terminal to verify XON/XOFF

handshaking is enabled.

3. Power up the system. CPU32Bug executes a self-test and displays the sign on

message (which includes version number) and the debugger prompt CPU32Bug>.

1.5 SYSTEM RESTART

There are three ways to initialize the system to a known state. Each situation determines the

appropriate system restart technique.

1.5.1 Reset

The M68300PFB platform board reset switch returns the system to a known state. When the reset

switch is first pushed the MCU send the default XON character to the terminal to prevent

possible terminal lockup. There are two reset modes: COLD and WARM. COLD reset is the

CPU32Bug default, refer to the RESET command description. During COLD reset a total

system initialization occurs, similar to the BCC power-up sequence. All static variables are

restored to their default states. The serial port is reset to its default state. The breakpoint table is

cleared. The offset registers are cleared. The target registers are invalidated. Input and output

character queues are cleared. On-board devices (timer, serial ports, etc) are reset. During WARM

reset, CPU32Bug variables and tables are preserved, as well as the target state registers and

breakpoints.

Use reset if the processor halts, for example, after a halt monitor fault, or if the CPU32Bug

environment is lost (vector table is destroyed, etc).

1.5.2 Abort

The M68300PFB platform board abort switch terminates all in-process instructions. When abort

is executed while running target code, a snapshot of the processor state is captured and stored in

the target registers. For this reason abort is appropriate when terminating a user program that is

being debugged. Use abort to regain control if the program gets caught in a loop, etc. The target

PC, stack pointers, etc. help pinpoint malfunctions.

Abort generates a non-maskable, level-seven interrupt. The target registers reflect the machine

state at the time of an abort and are displayed on the display screen. Any breakpoints installed in

the user code are removed and the breakpoint table remains intact. Control is then returned to the

debugger.

GENERAL INFORMATION

M68CPU32BUG/D REV 1 1-1

CHAPTER 1

GENERAL INFORMATION

1.1 INTRODUCTION

This chapter provides a general description, installation instructions, start-up and system restart

instructions, memory requirements, and a terminal input/output (I/O) control description for the

M68CPU32BUG Debug Monitor (hereafter referred to as CPU32Bug). Information in this

manual covers the 1.00 version of the CPU32Bug.

1.2 GENERAL DESCRIPTION

The CPU32Bug package evaluates and debugs systems built around the M6833XBCC Business

Card Computer. System evaluation facilities are available for loading and executing user

programs. Various CPU32Bug routines that handle I/O, data conversion, and string functions are

available to user programs through the TRAP #15 handler.

CPU32Bug includes:

• Commands for display and modification of memory,

• Breakpoint capabilities,

• An assembler/disassembler useful for patching programs,

• A power-up self test feature which verifies system integrity,

• A command-driven user-interactive software debugger (the debugger), and

• A user interface which accepts commands from the system console terminal.

There are two modes of operation in the CPU32Bug monitor; the debugger mode and the

diagnostic mode. When the user is in the debugger directory the prompt CPU32Bug> is

displayed, and the user has access to the debugger commands (see Chapter 3). When the user is

in the diagnostic mode the prompt CPU32Diag> is displayed, and the user has access to the

diagnostic commands (see Chapter 6). These modes are also called directories.

CPU32Bug is command-driven. It performs various operations in response to user commands

entered at the keyboard. Figure 1-1 illustrates the flow of control in CPU32Bug. CPU32Bug

executes entered commands and the prompt reappears upon completion. However, if a command

is entered which causes execution of user target code (i.e., GO) then control may or may not

return to CPU32Bug. This depends upon the user program function.

CPU32Bug is similar to Motorola’s other debugging packages, but there are two noticeable

differences. Many of the commands are more flexible with enhanced functionality. And the

debugger has more detailed error messages and an expanded on-line help facility.

eescale S

emiconduct

, I

Freescale Semiconductor, Inc.

For More Information On This Product,

Go to: www.freescale.com

nc...

1 2 3 4 5 6 7 8 9 10 ... 97 98

Commentaires sur ces manuels

Pas de commentaire

Motorola M68CPU32BUG Manuel d'utilisateur Page 5

Commentaires sur ces manuels

Produits connexes et manuels pour Téléviseurs et moniteurs Motorola M68CPU32BUG