Hi,
My customer would like to validate TPS650944 on their board with CPU removed. Therefore, they connect all the control signals (including PMICEN, SLP_xxx……etc.) to 3.3V directly which are originally from CPU. With such setting, their cold boot sequence can be executed well until PCH_PWROK rises after VSYS insertion. Therefore, the last thing is to enable BUCK2(VCCGI) through BUCK2CTRL register.
Since they don’t have CPU on board, they need other way to access PMIC I2C. I provided a USB2ANY box (the same one used with TPS650830EVM) to them for such test.
With this box connected to their board, their test set-up is as below.
-
Remove the external pull-up resistors to 1.8V on DATA and CLK pins of TPS650944. Since CPU is removed from the board, DATA and CLK pins are unconnected on this board now.
-
Connect DATA/CLK/GND from their board to the corresponding locations on USB2ANY connectors.
Since there’s pull-up to 3.3V on DATA/CLK within USB2ANY box, we expect it can work well with their board without external pull-up resistors.
After several trials, we still not able to read/write register on their board from USB2ANY. When we click either read or write, error message like below will appear.
Meanwhile, with exactly the same set-up, another engineer can access TPS650944 register on another board (a different project but with almost the same schematics design.) Besides, the same laptop with the same IPG GUI set-up can work well with TI’s TPS6094x EVM from my customer. Before CPU is removed from the board, the CPU works well with the PMIC as well.
I have no idea why it’s not working on their board, even I use my own laptop. (IPG GUI and USB2ANY are both updated versions.) We capture the waveforms when we read and write BUCK1CTRL register as below. It seems there’s no ACK from the PMIC?
BUCK1CTRL Write:
BUCK1CTRL Read:
We would need your help to clarify what could be the root cause.
-
Should they implement an external pull-up to 3.3V on their board?
-
Do you think the negative voltage on CLK waveform is an issue for this?
- 0x5E should be correct I2C address, right?
Please let us know your ideas.
Thanks!
Antony