UCD9240/UCD9248 I2C problems

You seem to have noise being coupled between the power rails and the I2C bus (e.g., signal grounds). Are the return currents on these two power systems kept separate? I.e., power supply ground to the power modules and signal ground to the UCD and power modules.

Given that you are using a Schmartboard, you should probably solder a decoupling capacitor directly across the UCD analog supply pins as closeto the IC as possible, to solve the reference stability issue.

I know I2C to be finicky in many applications (especially if a length of cable is involved), mainly due to its reliance on slow clock transitions. Depending on your specific hardware, you could improve I2C behavior somewhat by adding a small resistor in series with the clock line or reducing the size of the pull-ups.

Hi,

thanks a lot for the hints.

Oddly enough, I don't even have anything connected to the power rails at this time. Plus, I see exactly the same problem with a UCD90124EVM, so the problem doesn't seem to be caused by my prototype setup.

The I2C line already has a small resistor in place on the master side. I'll try to add another one on the slave side to see if it makes a difference. Reducing pull-ups did not help, changing various decoupling capacitors didn't help either, nor did changing the I2C cables or using a lab power supply instead of the power from the i2c adapter. Somehow the I2C master adapter and the UCD series don't seem to like each other; so far I don't have any problems connecting to other chips.

I am going to connect a scope and logic analyzer to the i2c bus to see if there is anything odd going on.

Guenter,
I think you may be fighting two issues here.  1.7V on the 1.9V core voltage is definitely not a good sign.  As Edgar points out, the UCD92xx devices have proved to be sensitive to the connection to decoupling on the 3.3V and 1.9V (BPcap) pins and ground pins.  Ideally, there should be no vias between the caps and the pins.  If this is contributing to the behavior you are seeing, you might try adding a 1.0uF MLCC cap to the V33A pin.  

However, the fact that you are seeing the same issue on the UCD90124 EVM suggests that there is also some signal integrety issues on the I2C clock and data.  Your plan to hook up a scope and look at the signals is a good one.    

Mark,

I agree.

On the I2C side, I think I know what the problem is. I noticed that for ACKs sent from the TI chip, the setup time from SDA low to SCL high is sometimes very low, in the range of 250 ns. This doesn't happen all the time - most of the time the setup time is around 4-5 uS. It is also independent of the I2C clock speed - the setup time is exactly the same if I choose a lower speed. But whenever it happens, the I2C adapter reports NACK even though the TI chip sent ACK.. Looks like the I2C adapter triggers on the rising edge of SCL and doesn't catch the correct state of SDA. No idea if there is anything I can do about that, other than by trying to use a different I2C adapter. Obviously it won't help to reduce the clock rate since that does not influence the setup time.

Odd, though, that this only seems to happen after I started to configure the chip.

Guenter,
SMBus and PMBus both incorporate clock stretching into the interface.  That is, the device holds the clock low while it evaluates the command before clocking in the ACK/NACK.  This clock hold-off varies bacause the device takes different amounts of time to evaluate different commands. 

Users of the device that have creating their own I2C interface in an FPGA and not taken SMBus/PMBus clock stretching into account have had probems.  Section 4.3 of the SMBus spec  (on which PMBus is built) goes into detail on this topic. 

Mark,

yes, I understand that clock stretching is used, and I can see it on the logic analyzer. Problem is that the setup time from data low to clock high is sometimes very low, about 250-300 nS. If that happens, my i2c test adapter interprets the result as NACK.

I'll try to create some screenshots and provide pointers to it.

I copied a set of logic analyzer screen shots to http://roeck-us.net/captures/.

I was able to capture data from an oscilloscope as a .CSV file. Same location as above, file names TSO00001.CSV and TSO00001.xls. The .xls file includes two charts with the failing access.

Signal looks clean enough to me, only if I interpret the data correctly, data setup time (data low to clock high) is just about 120nS, which might possibly explain the error. Any idea what I could do about that ?

Guenter,
I've got access to the screen shots.  I'm discussing with other engineers here at TI.

Mark,

sounds good.If you need better data from the scope, please let me know and I'll try. I am still learning how to use it.

I am in touch with the vendor of the I2C master adapter; they ordered some of the affected chips to try themselves. I also ordered another I2C adapter to see if it makes a difference. I'll post an update here if I have any news.

Thanks,

Guenter

Guenter,

Mark Hagen and I have looked at the waveforms you attached and did not see any glaring issues.  What size pull-up resistor are you using on the PMBus Address and Data lines?  The USB to PMBus adapter we use in our testing and development has 2.2kOhm resistors.

Regards,

Karl Northrup

Texas Instruments

I2C adapter side pullup is 2.2k. I also tried various pull-up resistor values on the chip side, as well as pull-ups on both ends. I also tried with and without series resistors on the chip side.

Unfortunately, that does not make a difference. Behavior and waveform is always the same. Once in a while the setup time (data low to clock high) is very low, and the access will fail.

Thanks,

Guenter