HP 64783A, Руководство пользователя

Страница: 660 / 816

Interpreting the trace list
There are some cases where a problem caused by an errant bus cycle does not show
up until many cycles later. The emulation-bus analyzer must be used to track back
through the sequence of events to the faulty bus cycle. Data problems will often
behave like this, but there may be other causes.
If the "h>" prompt is shown, indicating a double bus fault, and if there are only two
states in the tracelist, this indicates a problem with the fetching of the initial vectors.
h>tl
Line addr,H 68040 Mnemonic
----- -------- ------------------------------------------
0 00000000 $00000000 sdata long read
1 00000004 $000BADAD sdata long read
2
h>
The first two cycles in the trace list are the initial stack pointer and the initial
program counter. The initial program counter must be even or the processor will
immediately double bus fault. You should verify that the data captured by the
analyzer is what is expected.
If the data for the vectors is wrong, a trace should be set up to check for access
problems during the fetch of the initial vectors. If the data is completely incorrect,
suspect an address or strobe timing problem. If only a few bits are wrong or if the
data in the trace is correct, suspect a data timing problem.
If there are a lot of cycles in the tracelist, you need to start from the end and work
backwords to understand what caused the double bus fault. If the trace was
completed before the processor stopped, modify the trace specification to "trigger
on nothing" so that the last bus cycles that were run can be captured. Wait until the
emulator status shows a double bus fault, and then halt the trace.
tg never
reset the target system
es
th
tl -20
Chapter 18: Connecting the Emulator to a Target System
Verifying Operation Of The Emulator In Your Target System
630