STM32MP1 + STPMIC1: PMIC intermittently enters an unresponsive state

[radek_rokk]

Hello everyone,

We’ve been dealing with a puzzling power management issue on our board (battery-powered design). The PMIC (STPMIC1) intermittently enters an unresponsive state that we believe matches the state described in AN5861. We’ve already implemented the supervisory circuit, but in this case it doesn’t have the desired effect. We're about to enter production, and this issue is our final blocker. We’d appreciate any pointers on how to resolve it.

 

Part number

 

STPMIC1BPQR with the AN5861 supervisory circuit fitted

 

Environment

• STM32MP151AAB3
• The device is battery-powered; the battery is non-removable.
• The product is charged via a wireless charger (STWBC86).

 

Schematics

 

Please see parts of our schematics attached.

 

Details

• The unit appears to experience a brown-out/battery protection event. It seems to happen at very low battery levels.
• The unit sometimes does not respond to the power button afterwards, which essentially means the device is bricked.
• Putting the device on the charger does not resolve the issue.
• We have taken measurements on a device in the "bricked" state - the battery voltage is present at the PMIC, the INTLDO capacitor is maintaining 1.8V, and all the system rails are otherwise switched off. The pull-up on PONKEY is active.
• The device can be "unbricked" by either disconnecting and reconnecting the battery, or by shorting the INTLDO capacitor with a low value resistor. So, it seems that the AN5861 circuit may work, but under these circumstances it does not appear to have the desired effect.
• Another theory:
  • Would the PMIC entering the LOCK_OCP state cause this behaviour? If so, would we expect that the supervisory circuit described in AN5861 should restart the device automatically if the PMIC enters LOCK_OCP state (i.e. the monitored rail falls)?
  • If the PMIC enters the unresponsive state described in AN5861 (not LOCK_OCP), would you expect that the long press reset (PKEY_CLEAR_OCP_FLAG) would still be functional, or it would not have any effect?

 

Expected behaviour

 

After a brown-out / battery-protection event at low battery, we expect the AN5861 supervisory circuit to recover the device automatically when the battery comes back out of protection - without any need to physically remove the (non-removable) battery.

 

How to reproduce

• Put a unit with a low battery on the charger
• Wait until the device powers on and starts booting up (typically a few seconds)
• Remove device from the charger and wait until it shuts down
• After a number of repetitions (anywhere from a handful to 100+), the unit will eventually stop powering on

 

Occurence

 

The issue is sporadic and difficult to capture, but when it happens the impact is significant as it makes our device unusable. The issue has been observed on the majority of units we’ve made so far.

 

We do not yet have oscilloscope captures but are actively trying to obtain them.

 

Thank you!

!-->

[Vincenzo]

Hello radek_rokk,

 

without a scope plot of STPMIC1 Vin behavior it is not easy to answer the question.

We need to check in deep about some spikes or drop voltage that is triggered between 

POR threshold and Vin_ok threshold.

Without a picture it is very difficult to help in a right way, could you try to:

1. Re-program and change NVM content of the default Vin_ok voltage value (higher or lower) to see if the problem increases or disappear.
2. Re-program and change NVM content of the hysteresis voltage of Vin_ok
3. Increasing the total input capacitor (VSYS) for the STPMIC1

A scope plot during the test helps a lot even if the problem is not triggered just to see the Vin behavior the STPMIC1 is seeing

Let me know

 

Regards,

Vincenzo

[radek_rokk]

Hello Vincenzo,

 

Thank you for getting back to us. We managed to get the plots now. Please find them attached.

A normal power on is shown on the left. On the right is a capture when the PMIC became unresponsive. These tests are with a nearly depleted battery (~3.1V) and a low VBUS voltage (~4.3V) connected from a lab PSU to the BQ25619 directly (the wireless charger is bypassed for the test). The conditions are the same in both tests, except minor difference in battery voltage, after repeated power on attempts the unresponsive state is achieved.

 

Kind Regards,

 

Radek