Setting up a Trigger Program to Trigger on Events
Triggering Information
Setting up a trigger program to trigger on events and/or to selectively
store events is generally straightforward. Certain types of events
however may be difficult or impossible to detect reliably. The
situation is compounded by the fact that it may well be possible
to construct a trigger program which appears to be able to function
logically, to detect the event(s) of interest, and to carry out
appropriate action(s) in response; yet inspite of this, the desired
results may not be obtained, or only inconsistently obtained.
While conceptually the trigger program may be thought of as
constantly watching the bus (e.g., of the processor of the system
under test) and thus able to detect any and all events which occur,
this in fact is not necessarily the case.
In review, the logic analyzer's acquisition memory receives
bus samples which have been "approved" for storage by the trigger
program portion of the analyzer, which resides logically upstream
of the acquisition memory. Generally the trigger program logic
might not affect the flow of samples incoming from further upstream;
many times the trigger program merely waits for an event of interest
to occur, in order to determine when the acquisition memory should
be allowed to fill up. The trigger program does however have the
ability to decide whether certain samples should be stored or
not.
The trigger program is functional in all modes of acquisition
clocking: Internal (internally-timed asynchronous acquisition),
External (externally-clocked synchronous acquisition) and Custom
(a form of External clocking used with a software support package).
Functional only under Custom clocking is the Clocking State
Machine (CSM) logic, which resides logically upstream of the trigger
program logic. The CSM utilizes specially-designated Qualifier
probes to enable it to assist in the acquisition process to determine
which bus cycles are relevant and should be stored, and which
are unneeded and should not be stored. The CSM then acts effectively
to assist in taking over duties which otherwise the trigger program
would have to perform; this allows any trigger program used to
be geared specifically to the debug task at hand, and thereby
be simpler and easier to construct.
(Note regarding the Qualifiers that not only are the Q0, Q1,
Q2 and Q3 probes able to function as qualifiers (in addition to
acquiring data, as can all probes), but so are the Clock probes,
as well as the C2:0, C2:1, C2:2 and C2:3 probes. Which particular
probes (if any) are utilized by the support software to accomplish
acquisition qualification is determined by the design of the probing
support software and/or hardware.)
It can be seen that if an event occurs during a cycle which
the CSM has decided should not be stored, then the cycle (as thus
the event) will not be seen by the trigger program. Generally,
the CSM will see to it that samples representing normal bus activity
are passed through for storage. Such samples may be for example
cycles in which the processor requests access to a location in
memory, or in which data is transferred over the bus. Achieving
reliable triggering on events involving such samples should be
straightforward.
Other type of events may not necessarily be passed along by
the CSM, however. Consider the case of a processor employing a
low-true reset signal ("ResetB"). In order to trigger on the bus
activity which commences following reset, it may be desirable
to trigger on the trailing edge of ResetB. A trigger program may
be constructed to trigger when ResetB goes high (i.e., on the
rising edge of ResetB).
Such a program will be found to function properly and consistently
when Internal clocking is used, as well as when External clocking
is used. The trigger program may not operate at all when Custom
clocking is used, or it may operate erratically. The cause may
be understood to be the fact that the trigger program was not
necessarily passed the cycle in which the rising edge of the ResetB
signal occurred.
One way to insure that proper triggering occurs in such a situation
is to employ an all-cycles acquisition under Custom clocking.
Such an acquisition selection (when provided by the support software,
present on the Setup window under "More") causes the CSM to pass
every sample through to the trigger program. This guarantees that
the trigger program will see every single bus cycle that occurs.
An alternate approach is to look for completely different event(s)
to assist in causing the triggering to happen. For example, this
may involve triggering on the processor's request to access the
first location of the boot area of memory, which action is known
to occur following the end of reset. Such triggering would likely
not be affected by the CSM, unlike the attempt to trigger on an
edge of ResetB.
|
