I2C Monitor - Concept And Design

I2C Monitor – Concept
I came across an issue where some I2C communications between an FPGA and an EEPROM was giving troubles. The FPGA acted as controller between the software and the rest of the hardware; so there were two components to the issue: (1) software communications to the FPGA, and (2) I2C communications between the FPGA and EEPROM. I’m simplifying here of course, but that pretty much summarizes the issue. This I2C EEPROM was accessed every time the hardware power-up, and all its content was “read” by the FPGA (and passed on to the software). As luck would have it, every now and then something would be dropped on the communications. To isolate it a Logic Analyzer was used (and a lot of time). During all that I though; men it would be great if I had a monitor for the I2C communications, and one that can log for that matter. It probably wouldn’t have helped much in this case – but there were some other issues that were associated with this, which having such a tool would’ve helped a great deal. So the idea was born: I want an I2C monitor. Nothing new, in fact I pulled information from many other similar projects. My objectives:
(1) Should be able to monitor simple I2C communications between two or more devices (at up to 100kHz bus speeds).
(2) Should be transparent – does not respond, acknowledge, or in any way modify the communication.
(3) Should output the transactions through RS232.

Below are just a few of the contributors to the main idea:
• Design Note 48 (I2C Bus Sniffer)
• I2C Bus Sniffer on AVR
• The Secrets of I2C - An I2C bus analyser to let you satisfy your curiosity

I could use the Saleae Logic analyzer, but if we want to log transactions for a long time then we must dedicate the Saleae analyzer to the setup – I hate leaving the cool tools out in the open unnecessarily.

Still not sure how far I’m taking this; but we’ll see…


I2C Monitor– Design

The plan is to monitor simple I2C communications between two or more devices and output these transactions through RS232 to a PC. In some of the reference designs listed before, most of the work is done by the MCU. The MCU samples the SCL and SDA lines and has to determine the START and STOP conditions, as well as the normal data. The flow diagram sort of goes as follows:

70239

To help the MCU keep up with the data, we can add some external hardware to handle the Start and Stop conditions. This was done on both the “I2C Bus Sniffer on AVR” and “The Secrets of I2C” articles; as well as article “Robust I2C Slave Without a Sampling Clock”. Such an implementation will require four dedicated pins: three interrupt pins (one for Start condition, one for Stop condition, one for SCL), and one standard input for SDA. In addition the PIC is required to have built-in USART hardware.

To understand how create the two additional hardware blocks for the Start and Stop conditions we need to take a look at the next figure. During normal transactions the SDA (data) line is only allowed to change when the SCL (clock) line is at a logic low. A Start and Stop condition is then defined by a change of the SDA line when the SCL line is at a logic high; the Start condition indicated when the SDA transfers from at a logic high to a at a logic low with the SCL at a logic high, and the Stop condition indicated when the SDA transfers from at a logic low to a at a logic high with the SCL at a logic high.

70241

In order to identify these conditions and create simple pulses to indicate either condition, flip-flops are used. The following figure shows a dual D-type flip-flop configuration used to determine a Start condition.

70240

The following figure on the other hand shows a dual D-type flip-flop configuration used to determine the Stop condition.

70242

The Start signal should trigger an I/O interrupt on the MCU. The Stop signal should trigger a separate I/O interrupt on the MCU.

The MCU requirements, as I see them are as follow:
• MCU must be clocked at the highest MHz rate possible (this is to be able to keep up with high data rates during the interrupt routines)
• MCU requires dedicated USART hardware/pins
• MCU requires three interrupt pins

I chose the 18F1320 PIC for this application with the following specifications:
• 40MHz clock (10MHz internal – using x4 PLL)
• Two dedicated USART pins
• Four dedicated interrupt pins (one is shared with USART, so CCP pin is used as third)