user manual

Using the 162Bug Debugger

4-14 MVME162 Embedded Controller Installation Guide

The following is an example of a routine which builds a separate vector table

and then moves the VBR to point at it:

*** BUILDX - Build exception vector table ****

BUILDX MOVEC.L VBR,A0 Get copy of VBR.

LEA $10000,A1 New vectors at $10000.

MOVE.L $80(A0),D0 Get generalized exception vector.

MOVE.W $3FC,D1 Load count (all vectors).

LOOP MOVE.L D0,(A1,D1) Store generalized exception vector.

SUBQ.W #4,D1

BNE.B LOOP Initialize entire vector table.

MOVE.L $10(A0),$10(A1) Copy breakpoints vector.

MOVE.L $24(A0),$24(A1) Copy trace vector.

MOVE.L $BC(A0),$BC(A1) Copy system call vector.

LEA.L COPROCC(PC),A2 Get your exception vector.

MOVE.L A2,$2C(A1) Install as F-Line handler.

MOVEC.L A1,VBR Change VBR to new table.

RTS

END

It may turn out that your program uses one or more of the exception vectors

that are required for debugger operation. Debugger facilities may still be used,

however, if your exception handler can determine when to handle the

exception itself and when to pass the exception to the debugger.

When an exception occurs which you want to pass on to the debugger; i.e.,

ABORT, your exception handler must read the vector offset from the format

word of the exception stack frame. This offset is added to the address of the

162Bug target program vector table (which your program saved), yielding the

address of the 162Bug exception vector. The program then jumps to the

address stored at this vector location, which is the address of the 162Bug

exception handler.

Your program must make sure that there is an exception stack frame in the

stack and that it is exactly the same as the processor would have created for the

particular exception before jumping to the address of the exception handler.