I2CChip.com: Monitoring I2C Bus
There are 2 styles of monitoring the I2C Bus:
- When everything works: Deliberately sending diagnostic
messages / information from an I2C controller (a
microprocessor) to a PC for logging or ATE, servicing
etc.
- When it doesn't work: Spying on the bus for debugging
purposes
There are several ways to do this:
- Use an I2C to RS232 chip to send what you want.
- Use a semaphore memory to pass messages
- Use a dual port semaphore memory to pass messages
We have been asked for a chip for this. If we get enough 
requests, we will make it
available.
Dual port I2C mnemories are made for DDC (monitors). An
example is the Microchip 24LC41.
It has two completely separate I2C busses,
which can both access the eeprom simultaneously. This means there
are no issues of multi-mastering the bus. Just write when you
want. Its just too-easy.
This solution provides your equipment with EEProm that can be
used to store data, as well as allowing a PC to read out the
diagnostics any time it wishes.
Typically we keep a count of hours-run, number of power-ons,
number of watchdog time-outs for all systems we make.
Another good idea is to normally use an ordinary I2C EEProm,
but when you want to do some diagnostics, just plug the special
dual-port version, and connect to the PC with an I2C-2-PC
adaptor.
You can use a simple I2C ram chip (philips) or use the ram in
something else such as an RTC chip like philips PCF8583. It has
240 bytes of ram free for storing data, and writing diagnostic
messages.
Then you pick the messages up from the PC using the I2C-2-PC
adaptor.
As it is a lot more work for most users to support a
multi-master bus, you can just use one of the I2C-2-PC ports to
hold the systems micro in reset while you collect the data
- Use the LEDS on our bus
monitor board to make sure the wiring is OK. The BUSY
led shows you if START and STOP
conditions are being sent
- Use an ordinary digital scope. This is a good way to find
subtle timing or logic level problems. It is much easier
to watch messages if you can trigger off the START
condition. This makes it very easy to see what is going
on, and see the actual addresses and message
contents.Below is a start bit detector which generates a
pulse when the start condition occurs. A more complete
circuit like our Bus
Monitor board has a BUSY pin, and start bit
and stop bit triggers, LEDS etc.
- Use a fancy Agilent Mixed Signal Oscilloscope, logic
analyser etc. These claim to have dedicated I2C modes.
Get one on demo while you sort out that thorny problem...
- Use a bus monitor program like Warmcats "Cheap I2C". The drawback
of this is that it ties up a PC 100% whilst it's running.
Still, who doesn't have an old PC these days? Our Bus Monitor board has an
improved interface for for this built in.
- Get a Bus Protocol Monitor from one of the other
suppliers on our links
page. MCC are strong in protocol analysers for smbus.
- Check the power supply to all devices
- Check that SDA and SCL go to devices, and are not swapped
or shorted together
- Try using the bus to write to a known good device, I find
it very useful to have a board with a PCF8574 and 8 LEDS.
It is useful later for debugging programs
- Use a scope to monitor the bus. Check that the levels are
valid.
- Check that SDA transitions happen when SCL is LOW.
(except start and stop)
- A circuit that detects START/STOP is very useful for
triggering the scope at this point. An alternative is to
use a micro pin to signal that an I2C transaction is
about to begin.
- Use the scope to check the start condition is correct, ie
SDA falls when SCL is high
- Count the number of SCL edges in the address byte: I2C
has 9 bits per byte.
- Check to see if there is an ACK bit, ie does the slave
respond
- If the basic chip functions are OK, but the whole system
doesn't go, you might want a protocol analysing tool to
store long sequences in a form you can pore over.
sales@i2cchip.com
http://www.i2cchip.com
Phone +64 21 623-402
Please send us mail
telling us what you think about this page and how we might
improve it.