Part No.: MPTL-telos-I2C-Negative-Tester
• Pattern generator for legal/illegal I2C messages
• Configurable I2C timing on bit level
• Stress test I2C devices
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.
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.
A graphical user interface enables you to create complex test scenarios from existing elementary test steps without any programming. These test cases can be stored for later use and test reproduction.
Please be aware, the graphical interface shown here requires a telos Tracii XL 2.0 in addition.
I2C Studio offers the following predefined test cases:
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.
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.
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.
If you DUT is an I2C master there are a number of corner cases you probably want to verify making the telos Negative Tester the slave.
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.
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.
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.
In January 2016 a new edition was released.