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.

TPS65217 never recovers after Fault

Other Parts Discussed in Thread: TPS65217, TPS65910A

We use the TPS65217C only powered from AC. After a power loss on AC the PMIC enter's FAULT state which is correct. If the AC comes back after 50msec+ it does works - PMIC comes back running as it should.

But  if the AC comes back in a too short period the PMIC will not get back running (ever).

My guess is the AC edge is not detected by any reason. Note that the rise time <50msec so that shouldn't be a problem. 

Below is a scope screenshot - the upper line is the AC, the lower one is the output of the PMIC on SYS1,SYS2. It can be seen that AC drops below 4.3V so the FAULT condition is fine, than AC comes back quite fast (~25msec) but the PMIC never recovers.

From AC detection point of view the short drop time is the problem (saw many 50msec deglitches in datasheet) or more the fact that the AC does not drops <100mV before it comes back?

Is there any way to go around this issue? 

TY

  • Brown,

    For applications without a battery this issue may be encountered when the glitch on the AC or USB pin does not sufficiently discharge.

    The issue is that the device detects the removal but then fails to detect the re-application of the power supply.  This is due to the AC/USB detection circuits looking for power application to occur from a fully discharged state.

    Can you try this with the USB pin?

    Janice

     

  • Hi Janice

    The datasheet treats both the deglitch times, voltage levels in the same manner for both AC and USB - the only difference I could found is about current limits. We will give it a try (have to hack existing PCB so it will take 1-2 days) but to be honest I don't expect it to work. Unless You know something which is not written in the datasheet :) or I didn't catched it.

    Till we can hack our existing circuit one more question popped up - can this "detect" glitch avoided if we use the power on from battery side?

    The method is described in the datasheet (Figure 56. Power-Connection for Battery-Less ...) and looks something like this:

    TY,

    Brown

  • Brown,

     

    Try putting a pull down resistor, about 100K, on the system pin and see if that helps. This will drain the charge from the system pin so when AC is reapplied it will trip the power path circuitry.

     

    Janice

  • Hi Janice

    We already tried with a 330 Ohm - the result is reducing the probability of happening but it still happens ...
    We have to bypass the powerpath switching part of the PMIC and use only the rails I suppose.

    Brown
  • Hi Brown and Janice,

    i have the same issue (Post: TPS65217 Brownout), i'm tested the workaround with a 10k Ohm resistor, the brownout issue cannot be determined with the workaround.

    Put the Vsys goes not to GND, and i can't found any specifikation about the Vsys pin and the drop threshold!

    Sebastian

  • Sebastian,
    Yes the "detect" glitch avoided if we use the power on from battery side because the battery is hard wired to the system pin. The only thing is you need the push button to cause a power up event.
    Janice
  • Hi Janice,

    i know ... i worked with this usecase in a other project and i have any topic's with a power fault.
    Do you mean i must switch the Vsys to GND by a Powerfail, to avoid the Brownout issue?

    ciao
    Sebastian
  • Hi,

    I am experiencing the same issues. I am not using the battery input, only the AC input and need the device to startup without using the power button. I was experiencing the same problem with the device "locking" up off following power glitches.

    I had a 4.7uF capacitor connected to the SYS pins even though we are not using that function. I have replace the capacitance with a 10k resistor and see a marked improvement in performance.

    I still get a system lock-up, not power output from the PMIC if the glitch on the AC input is less than around 32ms.

    Is there anything else I can do to ensure the PMIC will always start?
  • Brown59592 said:
    From AC detection point of view the short drop time is the problem (saw many 50msec deglitches in datasheet) or more the fact that the AC does not drops <100mV before it comes back?

    I've noticed the PMIC retains internal state at quite low voltages: if the AC voltage rail drops to 1V and power is reapplied, the power-up sequence looks like that after pressing the power button in software-requested off-state rather than a "cold" power up from 0V. I'm not sure how low you can go before the PMIC loses all state.

    Janice Escobar said:
    The issue is that the device detects the removal but then fails to detect the re-application of the power supply.  This is due to the AC/USB detection circuits looking for power application to occur from a fully discharged state.

    I'm not sure what you mean here by a "fully discharged state". I've seen it will power up just fine from a partially discharged AC if this discharge happened slowly. On the other hand, the SYS line always remains charged in battery-powered applications.

    In any case it sounds like the state machine of the tps65217 could have used a bit more attention. Going into a lockup state is usually not a desirable thing. (This is also true for AC rising too slowly... I see no obvious reason why it could not simply switch on when an adequate voltage is reached, instead it will lock up irrecoverably until fully powered down again, not even long-pressing the power button works.)

    Brown59592 and others: in the problematic state you're encountering, does the power button trigger power up in your situation? If so, then external logic that pulls the PB input low if AC is high but SYS is low might work...

    Or maybe just a fat capacitor on the AC input to help avoid brief glitches?

  • Daniel Minors85 said:
    I still get a system lock-up, not power output from the PMIC if the glitch on the AC input is less than around 32ms.

    Interesting twist: when I tried to replicate this problem, the system actually booted even though the glitch should have been short enough (< 20 ms total, < 10 ms below 3.5V):

    However this was with the pmic in off-state prior to the glitch, since I've been analyzing power-up/down behaviour I configured my BBB to enter off-state a few seconds after power on. It would seem therefore the problem doesn't occur in off-state but requires active-state (or sleep-state I'd guess), unless there's some other relevant difference I'm overlooking.

    Legend: vertical range is 0–6V (1V / grid line), horizontal grid lines are 10ms, pink = AC, green = SYS, blue = BAT, yellow = PB_IN.

    BAT is only tied to BATMON. I've included it and PB_IN since I've noticed they are useful indicators of internal PMIC activity (and easy to access for measurement on a BBB). The behaviour seen here is typical for a wakeup transition while powered. Note that SYS is hidden behind BAT until the pmic exits off-state.

  • Matthijs van Duin said:

    Brown59592 and others: in the problematic state you're encountering, does the power button trigger power up in your situation? 

    Reset not working in this state (at least when I tried it). It's like it's powered off ...

    Matthijs van Duin said:

    Or maybe just a fat capacitor on the AC input to help avoid brief glitches?

    Doesn't really helps - the capacitor will increase or decrease the length of the "poweroff" which creates this issue but it will still be a 10msec period after the caps are emptied in which if the poweron happens the pmic won't recover. We tried it - the power off time increased from 500msec to 2.1sec but that's all. Many different times can be created with different resistors and caps on the output but it will still be there.

    With the resistor and caps the probability can be reduced but with a random switch on/off with a relay controlled with a Arduino I still managed to have one "freeze" from ~1000 switches. And since our product will have many power on/off's sooner or later every client will end in a freezed state. Maybe after a year but still will end there.

    And a thing which makes it even worse - we also have big barrel caps before the PMIC. When PMIC freezes the result is no LOAD on this caps.

    This caps can hold minutes the 5V on their output once they are charged and having no load - which means without cutting the power for 5 minutes the PMIC will never make a full power cycle again since the 5V will don't do a full on/off cycle on his input ... 

    In our case we bypassed the PMIC's powerpath mechanism renouncing to the USB power path - this solved our problem but it won't solve for anyone which needs USB power or battery power together with the normal input ...

  • Brown59592 said:
    Reset not working in this state (at least when I tried it). It's like it's powered off ...

    Although the events leading to it are different, it sounds like it's exactly the same state the PMIC ends up in when powering up AC too slowly: power is available, yet the PMIC refuses to use it no matter what.

    My impression is that in this state the PMIC is still operational in some sense: PB_IN is being pulled high to 3.4V, and periodic downward pulses are visible suggesting an internal oscillator is active. On the scope it looks the same as normal off-state, except somehow the PMIC believes no adequate power supply is available to allow a power up.

    Brown59592 said:
    In our case we bypassed the PMIC's powerpath mechanism renouncing to the USB power path - this solved our problem

    The USB path doesn't suffer from this problem? Interesting, though strange...

    Brown59592 said:
    it won't solve for anyone which needs USB power or battery power together with the normal input ...

    I noticed that introducing battery power will release the PMIC from lockup (at least the slow-AC-power-up lockup), so it's quite possible these issues disappear when a battery is present. In general I think battery operation was the primary focus.

    Regardless, I do consider these behaviours to be chip bugs, and they're quite annoying.

  • Matthijs van Duin said:

    The USB path doesn't suffer from this problem? Interesting, though strange...

    USB does suffers from the same issue.

    With bypass I meant the rails are powered different - like the schematic from here:

    https://e2e.ti.com/support/power_management/pmu/f/200/p/411370/1460432#1460432

    It's from the datasheet (Figure 56. Power-Connection for Battery-Less ...)

    Matthijs van Duin said:

    I noticed that introducing battery power will release the PMIC from lockup (at least the slow-AC-power-up lockup), so it's quite possible these issues disappear when a battery is present. In general I think battery operation was the primary focus.

    When battery is present is a different story since it will switch to the battery. It's a good question tough if in this "glitch" case will remain on battery even if power came back? But it's not my case anyway - we basically have one power supply, USB power was only for fast factory config but we can live without it ...

  • The power button has no effect when the PMIC enters the lockup state. I have also tried the reset input but this appears to behave a little like the power button, in that a long pulse > a couple of seconds (I haven't measured it) will eventually reset the PMIC.
  • We are also facing this exact same issue and have not yet been able to find a good solution. 

    Has anyone come to any conclusion on how to avoid this lock up condition? 

    Clearly using the battery input is not a suitable option if a push button input is required. Putting a large capacitor on the 5V input is not really a practical solution when space is constrained. 

  • It seems to me the TPS65217 simply is not well-suited for operation without battery. Maybe the TPS65910A does a better job?