TPS65023: I2C Comms failure to acknowledge

Hi Daniel, 

Thank you for reaching out on E2E, 

Are you able to walk me through your setup process you are taking to see each scope shot so I can maybe get a better idea of what could be causing the issue here?

Are these two separate TPS65023 devices/boards, or the same device under the different conditions ?
Or is this a seemingly random error for the same device under the same conditions?

Best Regards, 
Sarah 

Hi Sarah,

This is the same board, under presumably the same conditions. The first device on the I2C bus that the OMAP communicates with is always the PMIC. I have my scope setup to capture on the first rising edge of the data line in these scope shots in order to capture the first transaction on the I2C bus when the device powers up.

I was wondering if anyone knew if there would be a reason why the TPS65023 would not acknowledge in one case but it would in the other. Potentially I need to probe more nets that connect to the PMIC to find out why.

Could this be due to a potential design marginality or a race condition, whereby the TPS65023 is sometimes addressed over I2C by the OMAP too soon?

Hi Daniel,

Do you mean in the second case, the PMIC is not connected to the OMAP processor? Apologies if I am still not understanding the second scenario, in which the PMIC is acknowledged.

Is device still starting up okay when encountering the NAK error?

Please verify that the I2C lines are pulled up to a source between 1.45 V - VCC via 4.7k resistors.
And possibly check for any grounding issues? These are common causes of NAK errors.

What speed mode are you operating the I2C at?

Best Regards, 
Sarah 

The device still starts up and functions as normal, however, it is unable to communicate with the PMIC again after bootup.

The pull up resistors are pulled up with 2.21kohm resistors to VCC.

The speed is less than 100kHz.

I will be probing more of the I/O to the PMIC within the next few days.

Hi Daniel, 

Thanks for the information. 

Typically a 4.7kOhm resistor is used for the pullup value here. 

Looking forward to any more feedback you have after probing. 

Best Regards, 
Sarah

Hi Sarah, I think I know what is going on now.

I probed a working and a failing card. The failing card seemed to have current leakage which caused the I2C bus connected to the PMIC to float up prematurely, before the system came out of reset. Do you know how the slowly rising I2C lines could affect the PMIC I2C comms? Potentially the PMIC fails to communicate thereafter due to what it sees. Now I know that the root cause of the issue is the leakage of 1 rail into another, I need to omit this leakage.

I have the following scope shots to help visualize the issue. 

Firstly, the scope shot which corresponds with the failure: 

Lastly, the scope shots which corresponds with a PMIC which will communicate properly:

What I am interested in understanding now is why it was only the PMIC which was confused on the I2C bus. The other devices, i.e. OMAP, temp sensor, I2C expanders, were all not affected by this and were able to communicate with the master (OMAP-L138) just fine.

Hi Daniel, 

Can you clarify what pin PMIC_RST_IN is connected to? 
I suspect it may be to do with the timing of the reset pin with regards to the I2C timing.

Th PMIC may have stricter requirements regarding I2C and the state that it is enabled in before allowing I2C communications, compared to the other devices in your system. 

Best Regards,
Sarah

PMIC_RST_IN is connected to /HOT_RESET on the TPS65023.

Hi Daniel, 

Thanks for the info. 

One thing to note is that TPS65023 has a relatively longer minimum setup and hold time requirement for I2C (this was improved in TPS65023B)

Are these parameter lower for your other devices on the bus? This may be the reason for a discrepancy.

Best Regards ,
Sarah