Advanced Protocol Trigger Configuration

The difference between finding a bug in five minutes versus five hours often comes down to triggering. A basic edge trigger captures everything and leaves you scrolling through thousands of irrelevant transactions. A protocol trigger captures exactly the event you care about, placing it precisely in your acquisition window. Acute instruments support protocol-level triggering across all major serial buses, and learning to configure these triggers effectively is one of the highest-leverage skills for embedded debug.

Why Protocol Triggers Matter

Consider an I2C bus with eight devices. You are debugging a problem with one specific device at address 0x52. With an edge trigger on SCL, every single I2C transaction from all eight devices fills your capture buffer. You might need to scroll through hundreds of transactions to find the one relevant read from 0x52. With a protocol trigger set to trigger on I2C address 0x52, the instrument ignores all other traffic and captures precisely when your target device is addressed.

The same logic applies to every protocol. Protocol triggers reduce the time-to-insight from minutes of scrolling to zero. They are also essential for capturing rare events that would otherwise be lost in a sea of normal traffic.

I2C Address Trigger Setup

I2C protocol triggering on Acute instruments supports several trigger conditions:

Address match: Trigger when a specific 7-bit or 10-bit address appears on the bus. Configure the target address in the trigger setup dialog. You can specify whether to trigger on read, write, or both directions.

Address + data match: Trigger only when a specific address is followed by a specific data byte or sequence. This is useful when you want to capture a particular register write to a sensor, for example triggering on address 0x68, write, first data byte 0x1A (a specific register address).

NACK trigger: Trigger whenever any device NACKs. This is the fastest way to catch bus errors. You can further filter by address to catch NACKs from a specific device only.

Repeated start: Trigger on the repeated start condition, which is common in register read sequences where the host writes a register address and then issues a repeated start followed by a read.

Configuration Example

To trigger on a write to device 0x52 with register address 0x0F:

1. Open the trigger configuration panel and select I2C protocol trigger.
2. Set trigger type to “Address + Data.”
3. Enter address 0x52, direction Write.
4. Enter first data byte 0x0F.
5. Set the trigger position (pre-trigger percentage) to see what happened on the bus before this transaction, which is often critical context for debugging.

SPI Command Trigger

SPI is more challenging to trigger on because it lacks a standardized addressing scheme. Every SPI device has its own command protocol. Acute instruments handle this with a flexible byte-pattern trigger on MOSI, MISO, or both.

MOSI command byte: Trigger when the first byte (or first N bytes) after chip select assertion matches a specified pattern. For example, many SPI flash chips use 0x03 for a read command and 0x02 for a page program. Configure the trigger to match the MOSI command byte with chip select as the framing reference.

MISO response pattern: Trigger on a specific response from the slave device. This is useful for catching error status responses, such as a status register read that returns a write-protect error flag.

Combined MOSI/MISO: For full-duplex SPI where both directions carry meaningful data simultaneously, configure triggers that match patterns on both lines within the same transaction.

Configuration Steps

1. Select SPI protocol trigger and assign CLK, MOSI, MISO, and CS channels.
2. Choose the trigger line (MOSI, MISO, or both).
3. Enter the byte pattern to match. Use “XX” for don’t-care bytes in multi-byte patterns. For example, “03 XX XX 00” triggers on a read command (0x03) to any address where the first returned data byte is 0x00.
4. Set CS polarity (active low is standard).

UART Pattern Match

UART triggering uses pattern matching on the serial data stream. Since UART has no clock or framing signal beyond start/stop bits, the trigger engine must first decode the baud rate and framing before matching content.

Byte pattern: Trigger on a specific byte or sequence of bytes. This is useful for catching specific command strings in a debug console or control protocol.

Break condition: Trigger on a UART break, which is the line held in the spacing state for longer than a frame duration. Breaks are used by some protocols as a reset signal (for example, DMX512 uses a break to start each frame).

Framing error: Trigger when a stop bit is not detected where expected. This catches baud rate mismatches, noise-induced errors, and other line problems.

Configuration Steps

1. Select UART protocol trigger and assign the TX and/or RX channel.
2. Set baud rate, data bits, parity, and stop bits to match your system.
3. Choose the trigger condition (byte match, break, or framing error).
4. For byte match, enter the pattern. Multi-byte patterns match consecutive bytes in the stream.

CAN/CAN-FD ID Trigger

CAN networks can be extremely busy, with dozens of message IDs at rates of thousands of frames per second. Protocol triggering is essentially mandatory for useful CAN captures.

Arbitration ID match: Trigger on a specific 11-bit standard ID or 29-bit extended ID. This is the most common CAN trigger condition. Enter the target ID, and the instrument ignores all other traffic.

ID + data match: Trigger on a specific ID with specific data bytes. For example, trigger on engine RPM message 0x0C0 only when the first two data bytes exceed a threshold value, indicating an over-speed condition.

Error frame: Trigger on CAN error frames to catch bus errors. This is invaluable for diagnosing intermittent CAN communication failures caused by termination issues, ground offsets, or electromagnetic interference.

Remote frame: Trigger specifically on remote transmission requests, which some CAN networks use for on-demand data.

For CAN-FD, additional trigger options include triggering on FD frames specifically (BRS bit set), frame length (to catch DLC mismatches), and CRC errors specific to CAN-FD’s longer CRC polynomials.

Combining Protocol Triggers with State Triggers

Acute instruments allow you to build multi-stage trigger sequences that combine protocol-level conditions with state-based logic. This is where triggering becomes truly powerful.

Sequential triggers: Stage 1 triggers on an I2C write to a specific register. Stage 2 arms after Stage 1 fires and triggers on a subsequent I2C read from the same device. This captures the write-then-read sequence specifically, ignoring standalone reads or writes.

Protocol + digital pin: Combine a protocol trigger with a digital channel condition. For example, trigger on a CAN message with ID 0x100, but only when a GPIO pin (connected to a digital channel) is high. This lets you capture protocol events that occur only during specific system states.

Conditional counting: Trigger after a protocol event has occurred N times. For example, trigger after the 100th I2C NACK, which is useful for catching the point where an error counter would overflow in firmware.

Timeout Triggers for Missing Responses

One of the most underused trigger capabilities is the timeout trigger. Instead of triggering when something happens, it triggers when something fails to happen within a specified time window.

Response timeout: Configure the trigger to expect a response within a defined interval after a command. If the response does not arrive, the trigger fires. This is perfect for detecting devices that occasionally hang or respond late.

Bus idle timeout: Trigger when the bus has been idle for longer than expected. On a CAN network that should have periodic heartbeat messages, a bus idle timeout catches the moment communication stops.

Watchdog-style trigger: Combine a protocol trigger with a timeout to create a watchdog. If a specific periodic message stops appearing, the trigger fires after the timeout, capturing the last successful message and whatever happened afterward.

Practical Debugging Workflow

A structured approach to protocol trigger debugging:

1. Start broad: Begin with a simple protocol trigger (address match, ID match) and examine the captured data to understand normal behavior.
2. Narrow down: Based on what you learn, add data match conditions or multi-stage triggers to isolate the specific event of interest.
3. Add context: Adjust the pre-trigger percentage to capture activity leading up to the event. Often the cause of a failure is visible in the transactions that precede it.
4. Automate: For intermittent issues, combine protocol triggers with streaming mode’s “Mark and Continue” action. The instrument runs continuously, marking each occurrence for later analysis.
5. Correlate: Use the MSO3000 or TravelBus to add analog channels to the capture. Trigger on the protocol event and examine the analog signals at the same moment. Signal integrity issues that cause protocol errors become immediately visible.

Protocol triggering transforms a logic analyzer from a recording tool into a targeted diagnostic instrument. Investing time in learning the trigger capabilities of your Acute instrument pays dividends on every subsequent debug session.