TPS6594-Q1: The PMIC's BUCK5 is not output,but others is ok and the nRSTOUT is high,SoC can not work.

Hello Ye,

1. From the User's Guide GPIO8 of the PMIC detects the level at the beginning of start up, and depending on the level will include or exclude BUCK5 in the power sequence.

Please see section 2.2 Control Mapping: https://www.ti.com/lit/ug/slvuci2/slvuci2.pdf?ts=1729690176269

2. Please post the schematic and if you could provide oscilloscope shots for following signals:

A. GPIO8

B. nRSTOUT

C. ENABLE

D. BUCK5

I suspect that the GPIO8 is not being timed correctly and placing you in the PDN-3G to 3M mapping. If the schematic is sensitive you can always direct message me to send them.

Best Regards,

Nicholas McNamara

Hello,Nicholas McNamara:

Thank you for your reply, I am sorry to reply you so late, this problem was solved a week ago, at first we also suspected that it was the entry of PDN-3G or 3M that led to no output into BUCK5, but we measured GPIO8 was indeed low during bootstraping, which meant that it did not enter PDN-3G or 3M. Later, we found that the software set the value of 0X44 register to 0X08, while the value of NVM was set to 0X1E. Due to the rapid power-off of PMIC, the power fluctuation of VCCA was not large, and the value of PMIC register was still retained. We only need to set 0X44 to the value of NVM 0X1E before the system was powered off, and the problem would not occur again. However, why the setting of 0X08 will cause no output of BUCK5 remains to be studied, possibly because the power-off timing does not meet the requirements.

Best Regards,

Ye x

Hello Ye,

Just to clarify that the software is setting register 0x08 after powerup (assuming TDA is doing software), the one shown below to data 0x44?

I'll double check the default values, but I expect that by the time you have read 0x1E (data) back from register 0x08 that is no longer valid data. Reason for this assumption is that after a successful power up, all rails have gone up and the TDA starts running it's booting software where it will use the drivers to write to the appropriate devices via I2C. At this point BUCK3 should be up and the LSB which is BUCK3_EN should be enabled, hence the conclusion that the readback of the default of 0x1E to be incorrect.

Can you give a more detailed explanation as to when this write takes place and readback takes place? 

Best Regards,

Nicholas McNamara

Hello Nicholas,

I'm sorry that I didn't explain it clearly, which led to your misunderstanding.

What I mean is that  the software engineer sets the value of register 0x44(register address) to 0x08(register data) after power-on, but the default value in NVM is 0x1E(the register default data), as long as the software engineer does not set this register to keep the default value(0x1E), there will be no failure.

Best Regards,

Ye x

Hello Ye X,

Note that by changing FSM_TRIG_SEL you are changing the fault handling of the PMIC.

After doing the performed write to the FSM_TRIG_SEL, I did not experience any shutdown event, the PMIC stays up. So there are two things that happened: An error occurred that never was resolved and 15 attempts to power up failed causing lock out or when clearing the interrupts the NSLEEP Bits in register 0x86 weren't set before so by default the device will go into a power off mode.

Are you sure this was the only change in software that writes to the PMIC? I suspect more than likely other changes were done such as either not clearing ENABLE_INT or setting nSLEEP bits in register 0x86 then clearing ENABLE INT.

From the User's Guide: TPS6594133A User's Guide

BR,

Nicholas McNamara