Oscilloscope Triggering Advanced Course: Protocol Triggering

1. Here we see the Trigger setup dialog on a Keysight Infiniium S Series oscilloscope, configured for a specific protocol trigger: I2C, Start 7-bit Address, where a Write to Address = 0x7F occurs with Data 0x1234. This scope has multiple options for specific I2C triggers, configurable with the “Type” and “Fields” dropdown menus. These options vary significantly between scope models.

Hardware Protocol Triggers

Protocol triggering generally falls into two distinct categories: hardware triggers and software-search triggers.  We’ll discuss search triggers in the next article in the series; here, we’ll focus on hardware protocol triggers. A hardware protocol trigger is exactly what it sounds like: Dedicated hardware inside the scope analyzes the incoming signals and triggers when all of the configured conditions are present. Hardware triggers are almost always preferable to software-search triggers for reasons that will also be discussed in the next article (…arrrgh…the suspense!).

The available options for protocol triggering vary drastically between scopes. Some models don’t support protocol triggering at all; some offer basic triggers for only a few common protocols; some offer upgrade licenses and add new protocols and triggers with new software releases; while others require hardware options be installed at the time of purchase. Because such a wide variety of options and capabilities is available in different scope models, I will focus on examples to illustrate the power of protocol triggers, rather than exhaustively describe all of the possible options for configuring them.

Example 1: I²C

I want to set up my I²C trigger to only look at 7-bit addressed write packets with data[0] = 0x20 and data[1] = 0x21. Note that I have to tell the scope which protocol signals are connected to which scope input channels:

2. The Trigger and Protocol Decode setup dialogs are shown on an S Series scope. We configured the trigger as described in Figure 1, but we also have to tell the scope a bit more about how to decode the protocol (e.g., which scope input channel to consider the clock and which to consider data). In this example, we used the “Auto Setup” feature to configure the vertical offsets and thresholds, but we could do this manually as well (and on scopes without the “Auto Setup” feature, we would have to!).

3. Here’s the result of our I2C trigger setup. Note that on this scope, the protocol-decode information is displayed directly in the waveform display area alongside the signals, and we can see the decode of the packet we’re looking for: a 7-bit address write with data = 20, 21.

Typically, the trigger point (the instant the scope displays horizontally at t = 0.0 sec) for protocol triggers is the end of the last data you specified as a condition. In this example, the data[1] = 0x21 is the last condition we specified. Let’s zoom in horizontally and take a closer look at the trigger point.

4. In a closer (horizontally) look at our trigger point, we can see that the rising edge of our clock signal (scope input channel 1 displayed in yellow) is our trigger point. This makes sense because our I2C signal has a rising-edge-active clock. Looking at the protocol-decode information displayed below our data signal (scope input channel 3 displayed in blue), we can see that the clock edge on channel 1 corresponds to the end of the second data packet (data[1]) that held value 0x21.

It’s worth noting that placement of the trigger point, and reliable triggering and decode in general, relies on setting appropriate signal scale, offset, and trigger/decode thresholds. If you’re having trouble getting a protocol trigger to work correctly, check these settings before anything else! You will want to ensure that:

• All of the protocol’s input signals are scaled so that they use most of the scope’s vertical dynamic range (i.e., on a scope with eight vertical divisions, each signal should take up five or six divisions; it’s ok if they’re on top of each other).

• None of the signals are clipped on either the top or bottom of the screen (the signal trace shouldn’t touch the top or bottom of the display area)

• The thresholds for triggering and decoding (some scopes will use the same thresholds for triggering and decode; others offer separate thresholds) are set to the same value, and that the value is appropriate for the protocol (protocols may or may not specify vertical thresholds) and appropriate for the signal onscreen (should be roughly at the vertical midpoint of the signal).

Example 2: Four-Wire SPI

Some scopes allow the user to configure a protocol trigger on digital channels (also referred to as “MSO” channels, short for “mixed-signal oscilloscope”). This can be particularly handy when the protocol you’re working with involves a large number of signals. Let’s setup a four-wire SPI trigger:

5. This screenshot shows the Protocol Decode setup dialog on an Infiniium S Series scope. As you can see, four-wire SPI requires quite a bit more configuration than the I2C decode we set up in the first example. Note that we’re specifying digital channels as our sources.

6. Comparing this Trigger setup dialog with Fig. 2, we see that the available trigger configuration options are quite different between I2C and four-wire SPI. Note the “Source” dropdown here: It’s used to select between triggering on “Digital 2”, which is configured as the “MOSI” data source in Fig. 5, and “Digital 3” (not shown), which is configured as the “MISO” data source in Fig. 5. This distinction will become clear when we look at the result of our trigger setup in Fig. 7.

7. Here’s the result of the trigger we configured in Figs. 5 and 6. Note the highlighted packet in the protocol listing at the bottom begins with “FF” in the MOSI data section. Looking back at Figs. 5 and 6, we configured a trigger for data that begins with “FF” on source channel Digital 2 in Fig. 6, and configured Digital 2 as our MOSI data source in Fig. 5.

Now, let’s zoom in and take a look at the trigger point:

8. Taking a closer look at the trigger point of our four-wire SPI trigger, we can see that it lines up perfectly with the rising edge of channel D1. Glancing back at Fig. 5, we configured Digital 1 as our clock source and specified that it was rising edge active. Just like our I2C trigger in example 1, the trigger point falls on the end of the packet containing the last data we specified, and the end of the packet is denoted by the active edge of our clock signal.

I know what you’re probably thinking: “What’s the point of using digital scope channels for triggering when the digital nature of these channels hides the analog signal behavior that I’m trying to see in the first place?”

Great question (you’re getting pretty good at this!). Using digital scope channels for protocol triggering is really useful when you want to trigger on protocol activity, but analyze analog phenomena on another channel. For instance, you may be interested in observing droop on a power rail when a certain packet is sent that enables a current-hungry device. Here, the ability to time-correlate and simultaneously view digital bus data and analog signals becomes a powerful weapon!

9. This screenshot shows the same four-wire SPI trigger configured in example 2, with analog channel 1 enabled. In this case, it appears that analog behavior corresponds with the data in this packet!

Hardware protocol triggers can be an invaluable tool in the quest to hunt down difficult-to-find behavior and correlate it with activity that perhaps seemed unrelated. If you do any significant amount of work with communications buses, do yourself a favor and check out the protocol-triggering options on your scope. Then do yourself another favor and stay tuned for the next article in the Oscilloscope Triggering Advanced Course, where we’ll discuss sequence triggering and software-search triggers!