TPS544C26: TPS544C26 Intermittent I2C READ/WRITE NACK issue under SVID mode

Hi Caleb,

The device has been unlocked before doing I2C READ/WRITE. However, random register read/write NACK errors happens on a few boards.

Since the device is under SVID control for CPU application, will there be any conflict between I2C read/write and SVID control?

Thanks

Neo

Hello Neo,

A response will be posted by tomorrow.

Best,

Calan

Hey Neo, 

SVID and I2C interfaces are mostly isolated from each other. I don't think conflicting commands would cause intermittent NACK. Can you provide a list of the commands that are producing the NACK? I'd also put an oscilloscope on the CLK and DATA lines of I2C to see what the signals look like as you send a command that gets NACKed.

Thanks,
Caleb

Hi Caleb,

The NACK happens during random register read/write. So far from SW team's log, i can see NACK happened at least with below reading commands.

VOUT_STATUS 7Ah

READ_VOUT 8Bh

PROTOCOL_ID_SVID C2h

During debug, we tried to read VOUT_STATUS continuously, NACK happens after ~50 times read.

Below is the SCL/SDA from logic analyzer.

Please help check from your side on this.

Neo

Hey Neo,

I'm consulting our digital design team for their input. I will respond when they get back to me.

Thanks,
Caleb

Hey Neo,

A few follow up questions from digital design: 

After you get a NACK, does the next read/write produce a NACK? How are you setting the device address. Are you using a pinstrap address, or are you writing it and storing it to the EEPROM?

Also, do you have a filtering capacitor near the IC on the I2C lines? Can you show me on a layout?

Thanks,
Caleb

Hi Cabel,

In SW strategy, once a NACK is got, the test will be suspended and an error will be reported. We can't know if a NACK still got from next read/write.

Address is set through the pinstrap. This is an reference design from TI, there is no filtering cap near device I2C pins.

here is snapshot of schematic on SCL/SDA.

Here is the layout, I2C bus is shared with other TI multiphase devices.

Thanks

Neo

Neo.Wang 

This is Peter Miller, I am covering for Caleb while he is out of the office.  Thank you for sharing the schematic and the layout.

The logic analyzer is showing a NACK of the device Address in the second transaction, so it's not specific to the command being addressed.  Would it be possible to connect an oscilloscope to the CLK and DAT pins as close to the TPS544C26 as possible, relative to the AGND of the TPS544C26 device?  With the device address getting NACKed "randomly" I am worried their might be noise on the CLK or DAT that are corrupting the signal, resulting in the device not recognizing it's address.

Hi Peter,

Due to limited board availability, we are not able to probe SCL/SDA signal quality at this moment. Will try to do that once board is available.

Meanwhile, we have R02_D1/R03_D1 pull down resistors on I2C lines, both are not stuffed now. 

Guess we can try to stuff them with filtering cap to see if any improvement? if so, how much value of the cap can we use?

Thanks

Neo

Neo.Wang 

I would recommend starting with 10pF.

The I2C specification allows for upto 400pF per leg, but the real limiting factor is ensuring fast enough pull-up to meet timing requirements, which depends on the strength of the pull-up termination.  At 400kHz, (1.25μs high period) the pull-up / filter capacitance time-constant should be less than 400ns.

Hi Peter,

Our system run at 60khz or 100khz, we should be able to have higher value?

Btw, please keep this thread open, will share test data and may ask more questions for this issue.

Thanks.

Neo.Wang 

Yes, the slower frequency would allow a higher time-constant, but may also come with a weaker pull-up resistance, so it's a balance.  I would recommend a time-constant no more than 1/6th of the clock period (1/3 of the clock high time)