Hi,
I am writing a Linux driver for various PMBus devices. To test the driver with UCD92xx, I built Schmartboard based test modules for both ucd9240 and ucd9248.
With both modules, I see the same problems. First (not surprisingly, maybe), the voltage on BPCap is around 1.7V. It doesn't get better no matter what I do. I tried bypass capacitors all between .1uF and 1uF on different locations of the board with no avail.
I might be able to live with that (it is just for testing anyway), but there is a second, more severe problem: I2C commands send to the chips sometimes trigger a NACK response. This happens with both chips, and for I2C read and write commands. I tried changing the I2C frequency; when doing that, I noticed that the problem gets worse if I select 400kHz instead of 100kHz. Running at lower frequencies than 100kHz doesn't seem to make a difference. The situation gets worse if I enable more than one rail.
Is the I2C problem possibly caused by the BPCap voltage problem, or is there possibly some other reason ?
If I can not find a fix, I noticed that an evaluation module for ucd9240 was mentioned in another post. Is this possibly still available, and how can I get it ?
Thanks,
Guenter
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.
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
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.
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.
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.
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.