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.

Wednesday, 22-Nov-2017 17:36:01 CST    

Copyright  ©  Crescent Heart Software 2003