I2C Tutorial - JohnHau/mis GitHub Wiki

I2C Exerciser Advanced Trigger The Corelis I2C Exerciser software for CAS-1000-I2C/E and BusPro-I bus analyzers includes a powerful, advanced sequential trigger. Trigger sequences are defined using an intuitive graphical user interface (GUI) composed of different conditional elements commonly familiar to engineers and technicians with logic analyzer and oscilloscope experience. This tutorial is intended to introduce advanced I2C Exerciser users to the capabilities of the advanced trigger system.

Note: This tutorial is written for the CAS-1000-I2C/E bus analyzer and uses the master and slave emulation capabilities to demonstrate the trigger. The same advanced trigger capabilities are available for the BusPro-I and testing can be accomplished with a real slave device and the Debugger module.

The CAS-1000-I2C/E is a multifunction instrument that includes many functions from bus monitoring to master emulation to parametric testing—but, sometimes it may be necessary to collect additional data with another instrument. For example, it may be useful to capture SERDES signals on a high speed scope or monitor a parallel bus using a logic analyzer after a specific event.

To accommodate these requirements, the I2C Exerciser is capable of pulsing one or both of the discrete I/O signals of the bus analyzer. The SMB connectors on the front panel of the bus analyzer may be connected directly to the trigger in port on many test instruments. The diagram in Figure 1 depicts a common scenario for recording data with an external instrument.

The Goal: Trigger on a Sequence of Events In many cases it is ideal to trigger on a specific event or sequence of events, either to tag an entry in the trace list or to trigger an external instrument. For the I2C Exerciser software, trigger conditions are evaluated per transaction, where each transaction corresponds to a link in the monitor trace.

Complex sequences are enabled by defining states and the conditions under which the system will move from one state to another. When trigger conditions are met, the system will move to the next state as defined in the sequence. This may be an intermediate state, a previous state, or the final trigger state.

Figure 2 below shows two common trigger scenarios: non-consecutive events, where the system will trigger when each event has occurred regardless of intermediate transactions; and consecutive events, where the system will trigger only when the events are met during consecutive transactions.

Pulsing I/O The I/O can be configured as active HIGH or active LOW. The signal will be driven to the inactive state at the beginning of the test, and then pulsed to the active state for approximately 0.5 ms. This allows the AT1 or AT2 port on the front panel of the bus analyzer to be connected to the trigger input of an external instrument.

Note: The USB communication link between the bus analyzer and I2C Exerciser software will exhibit a typical latency of about 1.6 ms, though this may vary anywhere from 1.5 ms to 150 ms depending on transaction load. It is important to ensure that the instrument being triggered has enough pre-trigger buffer memory to overcome this delay.

Defining the Trigger Step 1: Identify the trigger conditions. For this tutorial, we want to tell when our temperature sensor reads temperature equal to 100 ºC on 3 consecutive transactions. The TC74 temperature sensor reports temperature data in response to the “Temperature Read (TEMP)” command. A value of 64h represents 100 ºC. The read temperature sequence is depicted in the Figure 3 diagram below.

Step 2: Plan the trigger sequence. It helps to take inventory of the events necessary to compose the trigger sequence. The list below covers the main components of the desired trigger sequence.

It should be a read transaction targeted at address A9. The data byte should be 64h, representing 100ºC. The data byte needs to occur in sequence 3 times. Ignore transactions not targeted at address A9.