Motorola M68CPU32BUG Manuel d'utilisateur Page 12

  • Télécharger
  • Ajouter à mon manuel
  • Imprimer
  • Page
    / 196
  • Table des matières
  • MARQUE LIVRES
  • Noté. / 5. Basé sur avis des utilisateurs
Vue de la page 11
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.
Vue de la page 11
1 2 ... 7 8 9 10 11 12 13 14 15 16 17 ... 195 196

Commentaires sur ces manuels

Pas de commentaire