telos I2C Negative Tester
I2C Tester for professionals
The most common use of an I2C interface is to send and receive data in compliance with the I2C specification. This implies that the device we are talking to is known to conform to the I2C standard, as well.
However, there are situations in which this particular aspect of a device is to be tested, i.e. where the goal is to determine whether or not a device is fully compliant with the I2C specification and how this device behaves in case of ill-formed signals.
I2C Testing with telos I2C Negative Tester
Our I2C Negative Tester is designed to fulfil all requirements introduced by this kind of application. It is capable of acting as master or as slave. In both roles it allows to control all relevant low-level aspects of bus communication, in particular it provides functionality to define the timing for each and every bit. It is even possible to send out patterns which violate the standard, e.g. make a “byte” six bits long. In slave mode the telos I2C Negative Tester permits to stretch the clock at any time. The user has full control over arbitration handling in master mode. Further more, independent configurable output signals can be used to trigger external events or to flag certain states in real time.
I2C Tester GUI
- USB 2.0 host interface
- Electrical and mechanical parameters are identical to telos Tracii XL 2.0
- I2C Fast Mode Plus: I2C Speeds up to 1 Mbit/s
- I2C High Speed Mode: 3,57 Mbit/s, depending on the telos I2C Studio version and the electrical attributes of your I2C bus. Update your product if you want to have this for previous purchases.
- Comprehensive scripting facility to define test cases. C# (C Sharp) is used as scripting language to allow for common constructs like loops and branches.
- Low level functions allow exact control of timing
- High level functions are used to generate standard I2C patterns
- Scripts are executed on-target, i.e. there is no USB latency to be considered when running the test scripts
- Control over arbitration behaviour in master mode
- Repeat functionality for stress tests
- Software-adjustable bus termination
- Set of sample scripts to get started
- Ability to generate independent output signals
- Seamlessly integrates with telos I2C Studio and telos telos 2C Framework
- TWI bus support
- Frequently asked questions
I2C Studio offers the following predefined test cases:
- The “master clock diversifying” test transfers I2C messages to the I2C bus, which contain longer pauses
between some of the bits. Using this test it is possible to check whether a slave works correctly with an
- The “master data” test transfers I2C messages with different lengths to the I2C bus.
- The “master speed” test transfers an I2C message with different bitrates. The purpose of this test is
to verify that an I2C slave supports the specified bitrates.
- The “master stop” test transfers I2C messages to the I2C bus, which contain STOP conditions at illegal
positions. E.g. a message like “Start, Addr, 5 Data Bits, Stop” gets created. The purpose of this test is
to verify that an I2C slave reset its internal state machine correctly after receiving a STOP condition.
- The “master stress” test transfers an I2C message again and again for a specified time period. The
purpose of this test is to verify that an I2C slave can process all I2C messages even on a fully loaded I2C bus.
- The “master timing” test transfers an I2C message to the I2C bus with different timings. Several
combinations of t_HD;DAT, t_SU;DAT, and t_HIGH are tested. The tested minimum and maximum values conform to the
values specified for standard- and fast-mode devices in the I2C-Bus Specification Version 2.1″, section 15.1.
Fast-mode plus is supported as well.
- The “slave” test emulates an I2C slave. The user can specify a frequency to which the slave stretches
the clock. If the master e.g. sends with 400 kHz a value of 20 kHz will slow down the transfer to 20 kHz. The slave
can send a NACK after receiving a specified number of bytes.
Even though the telos Negative Tester can be applied in a number of different ways the following use cases are the ones most commonly required.
As far as terminology goes we will refer to the tested device as the „Device Under Test (DUT)“. This is the component you want to test, not the part which drives the component as this is the telos I2C Negative Tester itself.
If your DUT is a slave then the I2C Tester acts in the role of the master and vice versa.
I2C is a transport mechanism, not the core feature of your DUT. Therefore it is important to look at test scenarios from different perspectives.
Electrical I2C Tests
The electrical layer is the physical connection. This includes the wiring as well as the termination and all electrical parameters related to it. The most important ones being the bus termination, capacitance on the bus and serial resistance. As these parameter have an enormous impact on test results your test setup should resemble the final setup as much as possible. The telos Negative Tester features two test pins which can be toggled arbitrarily during tests. The main purpose of them is to allow for real time modification of electrical parameters. In order to achieve this you should connect – for instance – an additional termination to the test pin via a field effect transistor which turns this extra bus termination on and off. This way you can test your DUT’s behavior with different terminations. In addition to altering the termination with a test pin you can apply the same method to add extra capacitance to the system. This is extremely useful because this load will drastically lower the quality of your signals and this is where most devices show problems.
Talking about signal quality, if you use the telos Tracii XL Analog option you can view the signals during your test runs.
One important point to remember for test design is the fact that since I2C is an open drain bus the timings actually seen on the bus not only depend on the timing of the bus clock but also on the electrical characteristics of the bus setup. A bus master will read back the clock and data lines before continuing with the transfer. If – for whatever reason – the signal quality is bad then there will be extra latency introduced by this fact. In contrast to bus systems with a fixed baud rate this is not critical at all as long as devices – especially your DUT – can cooperate with this effect.
Experience shows that many I2C devices show issues in situations where signals are non-ideal.
I2 Bus Timing
This is where we get the most questions about. The I2C specification mandates certain hold and setup timings depending on bus speed. The telos Negative Tester has the ability to generate both, valid and invalid timings. The standard behavior is to apply minimal timings. As mentioned in the previous section electrical parameters can make the timing slower, not faster. Therefore it is mostly not even necessary to alter the timings manually unless you need to test a particular case. Please refer to the low level API of the telos I2C Negative Tester for bit by bit timing manipulation.
There is one particular test setup you should run as timing test. Apply the highest possible termination which you want to support, make cables as short as possible and exercise your device at the maximum speed. This will verify if your DUT is fast enough to react at minimum hold times.
I2C Master Tests
- Does the master detect a bus busy situation?
For this check, put another master on the bus and keep the bus busy while attempting to use your DUT. The tracer will report bus errors – if any.
- Does your master cooperate with bus stretching between bytes and between bits within a byte?
This is where many master devices show issues.
- Arbitration handling: If your DUT should support a multi master environment it must also support the so called bus arbitration.
The best way to test it is with another master device addressing the same slave. Try to generate continuous traffic with both devices for a longer time – with in increasing probability you will run into an address arbitration scenario. Please note that this address arbitration only occurs if two devices try to talk to the same device at the same time. Don’t confuse it with a bus busy which is much more likely to happen.
- Bus blocking: How does your DUT behave if the bus gets blocked i.e. is pulled low for a longer period of time?
In pure theory the I2C specification does not define a stretching timeout but for all practical purposes you want to handle this situation gracefully.
- Addresses: Verify that your master is able to correctly address slaves with different address values i.e. if all bits of the address are considered.
- Speed: Test your DUT with various speed settings within the supported range.
I2C Slave Tests
If your DUT is a slave device there are a number of tests which you should perform regardless of the intended device functionality.
- Addresses: Configure the telos I2C Negative Tester to address your slave on all supported address values. This holds for 10 bit addresses as well. If your slave is a high speed device, please note that the telos Negative Tester supports to sett different values for the high speed token.
- Behavior on odd bit count: Configure the telos I2C Negative Tester to leave off a bit during transmission. An I2C slave should never ever leave the bus in a blocked (pulled to low) state for a longer time. This is a very common problem with I2C slaves and it is rather difficult to implement a robust system around them.
- Extra slow: Slave devices tend to show issues if communication speed gets to low so please do not forget a test with ultra-low speed.
- Bad signals: As mentioned in a previous chapter electrical characteristics have a large impact on I2C compliance and performance. Especially with the DUT being a slave it is desirable to run a test with a very low (weak) termination to verify that in such scenario the bus is – at least – never blocked.
Verifying device functionality
The telos I2C Negative Tester is a bus exerciser. It has no knowledge on the logical functionality of your device beyond the I2C interface.
Typically you want to verify if your DUT performs correctly rather than the pure I2C communication itself. For this purpose it is best practice to create a golden master i.e. a test run with known good results. This will produce a certain data stream in the i2cstudio tracer view. This data will include both, the sent and received messages. Regardless of the meaning of these messages they will almost certainly differ in case of higher level problems with their root cause in the I2C communication. So instead of attempting to evaluate the bus traffic on a low level it is advisable in most cases to focus on data evaluation. Please note that the telos I2cStudio offers a number of data export options for further processing within – for example – test scripts.
The telos I2C Negative Tester is based on the telos Tracii XL 2.0 platform. This let’s you work with your I2C Tester in the same hardware and software environment as for other I2C tasks such as tracing and bus control. The physical and electrical aspects of the telos I2C Negative Tester device are identical to the Tracii XL 2.0. If you are used to work with the telos I2C Framework, you will appriciate that working with the telos I2C Negative Tester follows the known concepts.
However it is not possible to use the telos I2C Negative Tester as telos Tracii XL appliance.
What You Need
For testing your I2C bus you need the following tools
These components are necessary for an ideal setup:
Ask for this product I2C Negative Tester Bundle, we have a special bundle price for, check our shop.
In case you already own a telos Tracii XL 2.0 with Tracer Option you just order the telos I2C Negative Tester plus cables.