While many times your attention as an engineer is focused on identifying trigger patterns based on the data contained within an I2C frame, sometimes there is much information to be found in those frames that contain no data at all. Using the LeCroy I2CBus TD package, and in particular the data length trigger conditions, focusing in on these special bus events allows you to quickly perform debug and verification on your design.

Frames with no data can occur for a number of reasons. One common reason for this to occur is when no device responds to a particular address. According to specification, I2C bus masters are required to terminate their bus transaction upon receipt of a “not acknowledged” bit. If this bit is present in the address byte, the master will generate a Restart or Stop condition before it has the chance to write data to, or read data from, the device at that address. There are multiple reasons why a device may not acknowledge its own address — it could be busy performing another operation, or there may not be a device on the bus with that address. Identifying these conditions is often very important to an engineer performing testing or debug. Figure 1 illustrates this type of bus transaction.

Figure 1:

An example of an I2C frame that contains an addressing error. Since the address is not acknowledged by any device, the bus master terminates the frame before any data bytes are sent.

Another situation where a frame with no data can occur is when the I2C bus master is addressing a particular device to perform a “heartbeat”style status check. To perform this type of check, the I2C bus master addresses a device and listens for the device to acknowledge the address. If there is an acknowledge, the I2C bus master has confirmed that a device on the bus is responding to this address. The bus master is now free to terminate the frame with a Restart or Stop condition before any data bytes are sent. This action is performed, for example, when a bus master is attempting to determine which devices are available on a bus at startup. Figure 2 on the following page illustrates this case.

Figure 2:

An example of a “heartbeat” style I2C frame, where a device acknowledges its address, and then the bus master immediately terminates the frame.

Setting up trigger conditions to identify these events is very easy using the I2CBus TD package. By using a Frame Length trigger where the Data Length is set equal to 0, triggers will only be produced for frames with no data bytes that otherwise meet the address, direction, and acknowledge conditions set.

An example of a trigger setup for such a case is shown in Figure 3. Observe that the Ack Setup control is set to search for a No Ack condition — this setting requires that at least one address/data byte within the frame have a “not acknowledged” bit associated with it (the Ack condition performs a similar operation, requiring at least one address/data byte within the frame to have an “acknowledged” bit set). This allows you to set up triggers to distinguish between cases such as the addressing error and heartbeat message examples outlined above.

Figure 3:

An example of a trigger on a frame with no data. Notice that the acknowledge bit is high (which represents a NoAck condition) in the frame preceding the trigger – this satisfied the Ack Setup trigger condition shown in the trigger setup

Note that while this example is utilizing a simple case for the data length trigger, all of the flexibility available for your use in triggering on data patterns is also present in setting data length trigger conditions, including the use of ≠, >, >e;, <, <e;, in range and out of range operators. This capability gives you another mechanism for discerning between different types of frames, allowing you to narrow your “field of view” to only the bus traffic you care about easily and quickly.