The I2C Analyzer was born out of the idea to write a Linux driver
for a device with Windows-only software support. Lacking the source
code for the Windows application a reverse engineering approach was
necessary to find out what the communication channels to the device
are. After finding an Atmel 24C256 on the board and other
indications in the data segments of the Windows executable it became
clear that I2C is the communication protocol being used. The next step
was to look at the Linux I2C protocol stack
[1] and to find out what the
best approach would be to access the device. The Linux I2C bus
driver i2c-parport-light turned out to be a perfect fit.
Unfortunately the device did not respond to i2cdetect
calls after adapting the i2c-parport-light driver to use the
serial port instead of the parallel port. The question was what went
wrong during I2C communications. The problem as a newbie to I2C is
that it is very hard to read the logging output of the Linux I2C
layer without putting them into a time context. Even worse the Linux
kernel logging demon seems to not always receive the log output in
the correct order so that tracking down the I2C communication problem
is very hard just by the I2C layer logging.
The only solution I could imagine was to develop some tools that write
timestamps and the associated SDA/SCL signal level changes into files
together with an application that
visualizes the recorded signal in a chart. The result of
these efforts is the I2C Analyzer Suite presented here.
Besides the graphical user interface, the tools provided by this suite do not work right out of the box. For tracing I2C communications on Linux you need to modify the source code of the I2C bus driver you want to trace. On Windows you need to adapt the example library which uses a Win32 API interception mechanism. Before that you need to find how the Windows application communicates with the device under investigation so that you can intercept the right Win32 API functions. When you don't have the source code available then your only chance is the reverse engineering approach and looking into the application binary with a Windows Disassembler.
TODO: Complete documentation [2], [3]
TODO: Complete documentation [4], [5]
TODO: Complete documentation
The format of the trace files is very easy. Each line of the file contains a timestamp followed by a signal level value, separated from the timestamp by a space character. The range of the signal level is either zero (0) for the lower level or one (1) for the higher level.
0000001717 0
0000002418 1
0030172715 0
0030173888 1
0030177854 0
0030179258 1
0030180458 0
0030181642 0
0030182863 0
0030190971 0
0030193118 1
0030195260 1
0030197977 0
0030199706 1
0030200403 0
0030201704 1
...
NOTE: The reason for the gap between the 2 msec timestamp and the 30 sec timestamp is that the application was idle for 30 seconds before a transfer was started.
TODO: Introduction
The Visual I2C Analyzer application takes a directoy as parameter, indicating where to find the four trace files, created either by the Linux driver or by the Windows API hooking code. If no directory is specified then the application is looking in the current working directory for the four files.
visuali2c.sh [<LogFileFolder>] (UNIX)
visuali2c.cmd [<LogFileFolder>] (Windows)
NOTE: The environment variable JAVA_HOME must
be set before launching the application.
The Java Swing application has a very simple interface layout. The first interface element is a slider, which allows you to zoom into and out of the data set. The default zoom level is 100 μsec/pixel. The zoom level can be changed by the slider between 1 and 1000 μsec/pixel. The next element in the user interface is the chart for the write operations, showing the SDA Write signal as green line and the SCL Write signal as red line. The third element is the same chart but showing the SDA Read and SCL read signals.
TODO: Make 0.0.1 release
If you want to trace other applications, then get the source-code from here and adapt the examples to fit your needs.
Please send comments to the
i2canalyzer-devel mailing list (NOTE: For spam protection
reasons you need to be subscribed to post to the list).
Bug
reports can be filed using the SourceForge
bug tracker.
The following list shows possible extensions:
Features will only be added when they are required for debugging purposes, the
I2C Analyzer Suite does not serve an end in itself.
Feel free to contribute bug-fixes or other features if you need them.
Author: Michael Rumpf (mrumpf __at__ users __dot__ sf __dot__ net)