TPS6593-Q1: TPS6593 go to safe recovery and shut down unexpected

Hello Tim,

since we offer the TPS6593 in different variations, can you give me the full part number or tell if the unit has been reprogrammed by your team?

Tim Tan said:

keep this voltage near 5S 

I'm sorry I don't under this portion of the post, the main system input to the board is a battery and when it drops to 3V3, then the battery input to the system will stay at "5S" voltage?

Tim Tan said:

1. Why does the PMIC TPS6593 go to safe recovery state? Is this because the power input voltage to TPS6593 has little voltage dropping?

I need the part number, anything else would be speculation without understanding your system and the test. It may be possible but depending on your system other portions of the board may gone outside of their tolerances and if the PDN is configured in such a way the PMIC will react to send the device in a safe state like above.

Either way, if there device still has it's VIO_IN up, I2C communication is possible (assuming VCCA is above 2V75), can you please provide a register read of 0x5A to 0x6C addresses, these are for the system interrupts on the PMIC.

Tim Tan said:

2. Can we modify some registers setting in TPS6593 side by I2C in order to prevent this behavior? 

Let's first understand what the cause is.

Best Regards,

Nicholas McNamara

Hello Nicholas,

1. The TPS6593 detail info: TPS65931211RWERQ1

2. Below mentioned "When the battery input drops near to 3.3V and keep this voltage near 5S", the "5S" in here means 5 seconds. We found kept low voltage a little time, this issue can be occurred easily.

3. VIO_IN is up, but TPS6593 has shut down all output, so AM62A7 can't communicate with PMIC by I2C. sorry for this.

And the power diagram is as below picture

Hi Nicholas,

Could you help to check this issue and feedback to us soon?

Hello Tim,

Tim Tan said:

1. The TPS6593 detail info: TPS65931211RWERQ1

Thank you that helps so very much and the diagram helps gives even further clarification, I'm assuming the primary power is coming from a pregulator output and the PG is the enable.

I'm going to be referencing this guide through out this post: TPS65931211-Q1 PMIC User Guide for AM62A

Tim Tan said:

2. Below mentioned "When the battery input drops near to 3.3V and keep this voltage near 5S", the "5S" in here means 5 seconds. We found kept low voltage a little time, this issue can be occurred easily.

Okay, makes sense, so without getting the interrupts what is said here is speculation, but the dropping the input source from the preregulator has lead to situation where an error occurs from one of the monitoring functions on the PMIC.

We can see that at least it tries to power up with GPIO4 being the first resource up.

With the original oscilloscope shot it's hard to tell where exactly in the power up sequence does the error occur, so please when trying the test again, work through the power sequence below and report back when it fails to come up.

Tim Tan said:

3. VIO_IN is up, but TPS6593 has shut down all output, so AM62A7 can't communicate with PMIC by I2C. sorry for this.

Now with power still to the PMIC & VIO on, you can probe the I2C lines to the PMIC and you can get the interrupts which would tell you specifically the error in the power sequence.

Now FB_B3 is used a separate voltage monitor & LDO1 is used a load switch each have target voltage of 3V3, with a 5% & 6% tolerance respectively.

So if either of these is below the target threshold and error will be flagged. Again, the interrupt would definitively say what the error is, I would try doing a readback after the test has concluded, I understand the AM62A isn't operation, but if you have separate device please use it.

Best Regards,

Nicholas

Hello Nicholas,

Thanks for your understanding to our power diagram and also clear this issue.

And add the power sequence test when it fails as below picture, please view

And I think this issue should be easy to be reproduced, could you also setup up this test in your side? (Connected TPS6593 to one Primary power, and adjust VBAT input into low voltage for Primary power to see TPS6593 behavior), which will better to see and analyze this issue.

Finally, it should be clear the PMIC TPS6593 goes to safety recovery status. So could you help to check whether it can be modified some register to avoid this error for TPS6593?  for example, cancel 3.3V input monitor ...

Hello Tim,

From your scope capture I can see it at least powers up BUCK5 so midway through the power sequence, is this the last resource that comes up?

For future scope shots, please just focus on one power attempt as it is hard to make out the voltage levels and timing.

Tim Tan said:

And I think this issue should be easy to be reproduced, could you also setup up this test in your side? (Connected TPS6593 to one Primary power, and adjust VBAT input into low voltage for Primary power to see TPS6593 behavior), which will better to see and analyze this issue.

I disagree, my tests are done on an evaluation board where the only IC is the PMIC where the resources have no problem using 3V3.

Tim Tan said:

Finally, it should be clear the PMIC TPS6593 goes to safety recovery status. So could you help to check whether it can be modified some register to avoid this error for TPS6593?  for example, cancel 3.3V input monitor ...

It can be done to MASK or disable voltage monitors, but some of the sequences do these changes as part of the start up. We need to first see the issue, again please find the last power resource to go up, give me an oscilloscope shot of the last rail to go up before they all start powering down.

Ignore the repeated attempts, only focus on the red:

Tim Tan said:

Connected TPS6593 to one Primary power, and adjust VBAT input into low voltage for Primary power to see TPS6593 behavior

Also in this part, there is no VBAT

Best Regards,

Nicholas McNamara

Hello Nicholas,

I got your point, thanks for your finds.

Please view the detail test wave when fails occurred as below, please help to analyze.

If any other info needs, please let me know. Thanks!

Hello Tim,

Thank you so very much for the scope shots!

So I'm expecting that the VDD_CORE on BUCK123 is set at 0V85 and that's why LDO3 isn't included in the power up, makes sense, if not please correct me.

Tim Tan said:

  

These two rails come up at the same time stamps and they're high power consumption rails, my assumption is that in the turning on these rails the VSYS_3V3 dips just beneath the 3V135, that's what looks like it happens on the lowering of the preregulator voltage can cause the load which is monitored by the feedback pin of buck3.

Now an I2C read after the recovery attempts would confirm this, but we can only go on with what we expected.

Now to confirm, what can be done is to disable the VMON on the power resources is to MASK the possible interrupts:

These are from the datasheet, please write 1 to the bits in BUCKn_UV_MASK on BUCK1, BUCK3, BUCK4

Best Regards,

Nicholas