This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TPS65917-Q1: I2C - no ACK

Part Number: TPS65917-Q1
Other Parts Discussed in Thread: TMP102

Couldn't make the TPS65917 to be accessed via I2C.  

I see pulses on both SCL and SDA (35, 36), but the TPS65917 don't provide ACK.

What might hold the TPS65917 from responding? 

I assume that once there's VIO and VCCa, it should respond on the I2C - regardless to VPROG, BOOT, PWRON, INT. etc.

I'm having MCP2221 master (USB to I2C), and TCA9548ARGER I2C switch.  The TPS65917 is connected to CH0, CH1.

There is TMP102 on CH2, and it responds correctly.

There are pull-ups to Vio.  Should I add capacitance.

Here's the sequence I used, using MCP2221 CLI:

@rem Access TPS65917 @ 48h - CH1 behind TCA9548 @ '71h'" 

"mcp2221cli" -i2cw=02 -speed=48000 -slave7=71   # Open CH1 of TCA9548 - connected to pins 35, 36 of TPS.
"mcp2221cli" -i2cR=1 -speed=48000 -slave7=48     # Access TPS - no response.

@rem Access TMP102  @ 48h - CH2 behind TCA9548 @ '71h'" 

"mcp2221cli" -i2cw=04 -speed=48000 -slave7=71   # Open CH2 of TCA9548
"mcp2221cli" -i2cR=1 -speed=48000 -slave7=48     # Access TMP102 - shows temperature

  • Hi Ishay,

    Welcome to E2E!

    In order to communicate using I2C, the following rails should be high: VCCA, VIO, and RESET_OUT. Can you verify that these are high?

    Also, can you take a scope shot of the SCL and SDA signals when you are doing a read or write? Please measure these lines as close to the PMIC device as possible.

    Thanks,
    Nastasha
  • Hi,

    Sorry for the delay - I have responded earlier but it was not taken for some reason.

    Anyway,

    I saw that VCCA and VIO are high, but RESET_OUT is low, which might explain the failure to access.

    I'm attaching the schematic - please see if you can suggest any wrong connection.

    With Regards, 

    Ishay

  • pmu.pdfNot sure if the JPG is good quality, so sending PDF, with the I2C connections.

  • Ishay,

    Thanks for sharing the schematic. There are a few notes I have:

    The SMPSx_IN capacitors should be 4.7uF

    The SMPSx_SW capacitors should be 47uF

    How are you turning the PMIC on? It need an on request to be able to turn on. This means either POWERHOLD (GPIO_5) needs to be pulled high or PWRON need to be toggled (high-low-high).

    Thanks,

    Nastasha

  • Nastasha,

    Our design has options to use LDOs and DCDCs, as well as the PMIC.   Up to now, we used the LDOs, and now we started to debug the PMIC...     

    I assume that we missed a power-switch on PWRON.  I assume that there is no need for capacitor or any other debounce mechanism.

    I have connected the PWRON to on-board 3.3V GPIO, and toggled it several times, and afterwards tried to access the PMIC, without success.

    Can you detail the power-up sequence?

    Looking at figure 5-4, I see that VCC(A) is creating internal VCC_SENSE and VRTC, as well as internal 32KHz clock, and the RESET_OUT will go high some time after providing VIO - there is no POWER_ON event in this figure.

    Figure 5-4 also shows 'T1' - delay of 6ms from VCC to VIO.  Could it cause RESET not going high?

    You have specified that I can connect GPIO5 (POWERHOLD ) to a high level, for power-up.  I assume that this is 3.3V.  Can you please refer me to the datasheet section on it?
    My understanding was that this pin power-up as GPIO.

    Thanks for your support.

    Ishay

  • Ishay,

    Table 3-1 describes that POWERHOLD can be pulled up to 1.8V-5.25V.

    Table 5-1 shows the ON requests that you can use to turn on the PMIC. POWERHOLD going high is one of the events. GPIO_5 is already configured as POWERHOLD by default. Pulling this pin high turns the device on and pulling it low will turn the device off.

    If you use PWRON to turn on the device, it will turn on when it sees a high->low->high signal. However, it will not stay on unless POWERHOLD is pulled high, or AUTODEVON (register bit) is set to "1". This is described 5.3.5 section of the datasheet.

    Thanks,
    Nastasha
  • Ishay,

    Also, the 6ms timing between VCCA and VIO prevents any unwanted glitching to occur on the GPIO lines while the OTP registers are being loaded. It will not prevent RESET_OUT from going high.

    Thanks,
    Nastasha
  • Thanks Nastasha.

    It works! 

    I've connected GPIO5 to VCCA, and now the RESETOUT is HIGH, and I can read ('0') from 58/59/5A/5B.

    I would recommend to clarify the point on GPIO5.

    With Regards, 

    Ishay

  • For some reason the RESETOUT is high only on two boards, and in one of them sometimes it is low and sometimes it is high.
    What might be asserting RESETOUT low?
  • Ishay,

    RESET_OUT will not go high if there is no ON REQUEST or there is an ON REQUEST GATING condition present. See Section 5.3.2.1 of the datasheet to see the list of ON requests and gating conditions.

    Thanks,
    Nastasha
  • Hi

    I have connected a switch to POWERON and GND, and pressed several times, but RESETOUT still in low level.

    Is there a need to debounce the switch?

    Thanks for your support.

  • Ishay,

    If you use PWRON, you will need to pull POWERHOLD high or set AUTODEVON bit to "1" to remain on. Can you take a scope shot when pressing the button (including PWRON, RESETOUT, VCCA, POWERHOLD)?

    Thanks,

    Nastasha