Just recently, I was trying to finish a project which uses a couple of video-processing ICs that are programmed via the I²C 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 I²C 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 I²C in the first place. After all, if anyone should be expert at solving I²C 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 I²C 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).