Contents
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.
Figure 1. 4-wire SPI bus configuration with multiple slaves
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.
Figure 2. Example flow charts for common trigger state/event sequences
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.
Figure 3. Read temperature command sequence for TC74
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.
Figure 4 below is a representation of the intended trigger sequence as a flow chart.
Figure 4. Tutorial trigger sequence flow chart
Step 3: Implement the trigger sequence.
Open the Trigger Interface
Begin by opening the trigger definition interface. To open the trigger interface:
- Launch the I2C Exerciser software.
- Select the Monitor module by clicking the Monitor icon.
- From the menu, select Trace | Trigger…
The trigger interface begins in Design Mode. By default, the trigger comes pre-populated with TxType, Address, and AddrType conditions to allow triggering on a simple event.
Load a template
The software includes built-in templates for common trigger tasks. For this tutorial, we will begin with the “single event repeated for N times consecutively” template. This is useful for finding when an undesirable event happens repeatedly—for example, if a slave address is NAKed for multiple transactions in a row for a short period, it may be useful to trigger on that event to evaluate a malfunction of that slave device.
To load the template and begin editing, click New… and select “single event repeated for N times consecutively”. Click “Create…” to start a new trigger definition based on the template. The loaded template should resemble Figure 5 below.
Figure 5. Trigger template for single event repeated for N times consecutively
Customize the trigger sequence
We are now ready to customize the template for a specific requirement. First, the template needs to be adjusted to count 3 consecutive events instead of 4. Under the START state, change “Set C1 to 4” to “Set C1 to 3” either by double-clicking on the value or by right-clicking the value and selecting “Edit”. We will decrement the counter every time the desired set of conditions is met.
Define the conditions
Now we should define our conditions. Note that there are 3 sets of IF/ELSEIF statements, each with an AND operator. The first IF & THEN pair checks if the transaction conditions have been met and, if so, decrements the counter. The statement pair—which uses an ELSEIF instead of IF—again checks if the transaction conditions have been met and whether the counter has been completed and, if both sets of conditions are met, fires the trigger. Finally, the third ELSEIF & THEN statement pair resets the counter if any 7-bit address transaction with an address other than specified value (A0) is evaluated.
We only want to trigger on read transactions targeted at address 9A. Add a condition by right-clicking the AND operator under the IF statement and choosing “Insert After | Compare R/W | Read”. The Trigger tab should now resemble Figure 6 below.
Figure 6. Trigger tab with “R/W = Read” condition added
Next, we add a condition to evaluate the data byte and match the value “64h”. To do this,right-click the AND symbol again and choose “Insert After | Compare Data Byte | equals”. Enter the values 64, FF, and 0 as prompted. This means the data byte must equal64h with a mask of FFh (evaluate all bits) on the data byte in position 0 (the first data byte).
Finally, change the “TxType = Addr” value to “Data” and change the “Address = A0” value to 9A either by double-clicking the value or by right-clicking the value and selecting “Edit”. The Trigger tab should now resemble Figure 7 below.
Figure 7. Trigger tab with completed first Subtree
Now that the initial event has been defined, the main values included in this Subtree can be copied to the other two conditional statements. First, remove the existing conditions Subtree by right-clicking the AND symbol under the first ELSEIF statement as shown in Figure 8 below.
Figure 8. Subtree context menu with “Delete Subtree” selected
The ELSEIF statement now has no event Subtree. Repeat the process for the second ELSEIF statement.
We are now ready to copy the first Subtree to replace the deleted conditions. First, right-click the AND symbol under the first IF statement and select “Copy Subtree”. Next, right-click the first ELSEIF statement and choose “Paste Subtree”. Finally, right-click the second ELSEIF statement and choose “Paste Subtree”. The Trigger tab should resemble Figure 9 below
Figure 9. Trigger tab with copied subtrees
The new conditions need to be adjusted. The first ELSEIF statement should move to theTRIGGER state when C1 reaches 1. Double-click on the entry “C1 > 1” under the firstELSEIF statement and choose “C1 = 1”.
For the second ELSEIF statement, we want the conditions to be met when the data byte does not equal 64h, regardless of counter state. To fix this, double-click on the DataByte entry to edit it and select “!=”, “64h”, “FF”, “0”. The counter value should not be evaluated for this set of conditions, so right-click the value “C1 = 1” and choose “Delete”. The Trigger tab should now resemble Figure 10 below
Figure 10. Trigger tab with completed conditions
The ELSEIF statement now has no event Subtree. Repeat the process for the second ELSEIF statement.
We are now ready to copy the first Subtree to replace the deleted conditions. First, right-click the AND symbol under the first IF statement and select “Copy Subtree”. Next, right-click the first ELSEIF statement and choose “Paste Subtree”. Finally, right-click the second ELSEIF statement and choose “Paste Subtree”. The Trigger tab should resemble Figure 9 below.
Figure 9. Trigger tab with copied subtrees
The original template was configured to evaluate 4 consecutive events, but we only need 3.Double-click on the entry “Set C1 to 4” in the last THEN statement and change the value to “Set C1 to 3”.
Define the trigger event
Finally, we want to trigger an instrument with an active LOW pulse. Find the “Pulse IO: None” event in the TRIGGER state at the bottom of the window. Double-click the entry and choose “PulseIO1: ActiveLow”. If you have not already done so, the discrete IO signals will need to be configured as “Out” using the Configuration Manager interface. The final sequence should resemble Figure 11 below.
Figure 11. Completed trigger sequence
Finally, click “Save As…” and give the file a name to save your work, then switch the radio button at the top to “Enable Trigger (Active Mode)”. The next time the Monitor is run, the Trigger will be active.
Testing the Trigger
The CAS-1000-I2C/E emulation features provide a convenient toolkit for testing trigger conditions before attempting to collect data in a live system.
Master emulation
The CAS-1000 can be used to emulate the master that we will be evaluating—this is very useful for verifying the trigger script. The master emulation script below emulates a master reading data from a tc74 temperature sensor using the “Read Temperature (TEMP)” command. The script sequence below can be used with the CAS-1000 Emulator module with the setting “Forever” to continuously read temperature values from a tc74 temperature sensor.
main()
{
b10Bit = FALSE; // addr type
// define address and command codes
nAddr = 0x9A;
nRTR = 0x00; // Read Temperature (TEMP)
nRWCR = 0x01; // Read/Write Configuration (CONFIG)
// write command code and create repeated start
strCommand = integer_to_string_hex8(nRTR);
send_message(nAddr, b10Bit, strCommand, FALSE);
// receive one byte
strRet = receive_message(nAddr, b10Bit, 1, TRUE);
print("Temperature: ");
print(strRet);
print("\n");
// pause for 100 ms
pause(100);
}
|
The code above can be saved in a master emulation script (.SCR) file and used with the CAS-1000-I2C/E master emulation module.
Slave Emulation
The slave SDF file should include conditions that cause the trigger to fire as well as some negative test cases. The slave data below will cause the trigger sequence that we have defined fire on the third consecutive “64” value. Save the code below in a slave data (.SDF) file to use it with the CAS-1000-I2C/E slave emulation module.
// Sample Data 50 52 51 54 55 57 58 58 59 60 59 60 60 59 60 60 61 61 62 62 61 63 62 61 63 63 64 63 64 64 64 64 |
Putting it all together
Now that the emulation files are ready, we can test the Trigger sequence. First, click on the Emulator icon to launch the Emulation Manager. Click the Add… button to add an emulated device. Select “Slave” as the type, give it a name such as “TC74”, and then enter an address of “9A”. Select “Forever” in the “Runs” drop-down box and use the “Browse…” button to find the script file. When done, the window should look like Figure 12 below.
Figure 12. Emulated slave device definition
Click OK to save the slave definition.
To add the master emulation script, click the Add… button once again; but, this time, select “Master” as the type. Change the “Runs” value to “Forever” and use the Browse… button to find the master emulation script file. The window should resemble Figure 13 below.
Figure 13. Emulated master device definition
Click OK to save the master definition and we are now ready to run the scripts.
Click the Run icon to start the emulated devices. The Status for both the master and slave should now display “Running”. Click the Monitor icon to return to the Monitor. If the Trigger tab is not already visible, use the menu to select “Trace | Trigger…” to bring up the definition window. Change the mode from “Disable Trigger (Design Mode)” to “Enable Trigger (Active Mode)” to arm the trigger. We are now ready to collect data to test the trigger!
Click the “Run Single” icon or press F11 to start the monitor. The system should trigger almost immediately once the monitor starts—check the trigger status by changing from the Trigger tab to the Run Status tab in the Monitor Tools window. The status should include the word “Trigger” in red text to indicate that the trigger conditions were met.
The monitor window should resemble Figure 14 below. The master and slave were running continuously in the background, so the line numbers will vary depending on when during the sequence the monitor was started.
Figure 14. Monitor window showing trigger event
Additional Tips
The advanced trigger function of Corelis bus analyzers is highly configurable and very powerful. The tips below will help you get the most out of your bus analyzer.
Make use of the master scripting function for testing your trigger
Many events are infrequent, intermittent problems—if an event only happens every few days, it is important to test the trigger prior to gathering data. The master script function or Debugger module can be used to mimic the system master to make sure that the CAS-1000 triggers on the desired event.
Use the built-in templates
Templates for many common scenarios included in the I2C Exerciser software—simply change the conditions to the desired values and these trigger definitions are ready to go. To access the templates, open the Trigger tab and click the New… button and a list of pre-made trigger sequences is available.
Remember to use a generous pre-trigger buffer on external instruments
The I2C Exerciser software is dependent on the non-real-time host PC OS to process the trigger sequence and send the trigger command back down to the bus analyzer hardware. Depending on transaction load and host PC processing power, this may cause a delay between event and trigger. Additionally, try to avoid any extra load on the host when gathering data to ensure all available resources are available for the bus analyzer software and hardware.