Just recently, I was trying to finish a project which uses a
couple of video-processing ICs that are programmed via the I2C bus.
However, I struck trouble with one chip. For some reason, it wasn’t responding
correctly to the set-up data I was sending to it from the project’s
microcontroller, even after I had been through my control program umpteen times
searching for bugs (or programming errors).
Fig.1: the basic arrangement for the LPT to I2C interface. Mosfets Q1 & Q2 pull down the SCL & SDA lines for outgoing signals from the port, while the inverters interface the incoming SCL & SDA signals from the circuit under test.
Even when I wrote a test program and captured the
I2C bus activity with my digital scope, I still couldn’t track down
the source of the trouble.
Fortunately, before tearing out the last few strands of my
hair, I decided to seek help from the support people at NXP (formerly Philips
Semiconductors) – not only because the chip concerned happened to be one of
theirs but because it was Philips that developed I2C in the first
place. After all, if anyone should be expert at solving I2C problems,
it should be NXP.
As it turned out, they were very helpful. An NXP support
engineer promptly sent me an email suggesting several things to try. Then, when
that didn’t fix things, he suggested I try analysing the problem using a
debugging program running on a PC. Not only that but he also sent me a copy of
the latest version of their free I2C debugging program (called
"URD"), which they developed quite a few years ago. The current version turned
out to be v3.12, which comes as a self-installing package called URD312.exe
(more on this later).