stpmic1 enter to unknown state when the board is powered with a specific ramp and is unable to power up

[RBors.1]

Hello,

we are making qualification stress tests on our custom STM32MP157 board. One part of these tests consist to power the board with custom ramps that simulate the worst power scenarios (as glitches, slow ramp, brownout and blackout).

We use the P/N STPMIC1APQR and we want the system to always (auto) power up when the Vin is stable.

We found, at the moment, two scenarios that prevents the PMIC to start:

1. single hole on Vin (5V nominal) with a minimum level >Vin_por_fall, <Vin_ok_fall
2. multiple fast holes on Vin (period 14ms duty 50%) with same levels as 1.

All scenarios are perfectly reproducibles and leads to the same results.

The first scenario is explained in the datasheet as a turn-OFF condition triggered by VIN_OK_Fall. By pressing the PONKEY button the system is able to boot.

In the second scenario pressing the PONKEY button will not restart the system. The only documented PMIC state that explain this behaviour is the LOCK_OCP state, indeed the PMIC will only leave this state by lower the Vin under the Vin_por_fall level.

However we can not explain how the PMIC could enter in this state as the NVM register LOCK_OTP is cleared and no overcurrent should happen.

Here follows my questions:

1. is there a known method to prevent these locks?
2. how could the PMIC behaviour in the second scenario be explained?

I'm available to share some oscilloscope plot to further explain the problem.

Best regards,

Rosario Borsellino

[Ara.1]

Hi Christophe,

Thank you for PMIC behavior, but i don't see any console prints on debug UART, like loading of TFA, U-boot FSBL or U-boot SSBL , i am using yocto BSP, may I get a software patch/ line changes for this scenario, so that i can retest and get the observations.

Thanks,

ARP

[DPrai.1]

Hi Christophe,

In case VIN drops but keep above VIN_POR_Fall, is it possible that software doesn't have the time to set Restart_request bit ?

Exemple : No_supply -> Preload_NVM -> Check&Load (MAIN_CR is resetting by default [0x00], Restart_request = 0). -> Power_Up ->No time for setting Restart_request Bit -> Power_Down -> OFF. -> Waiting For Turn on Condition

If the system doesn't have Turn On Condition, what happens ?

Thanks,

David

[Vincenzo]

Dear DPrai. 1,

usually Buck3 is used to supply the VIO domain, if this voltage is missing there is no I2C BUS communication (even if I2C is alive inside the device). If you can supply externally the VIO so you are able to send a WAKEUP command to turn ON again the device, but not via I2C.

Best Regards

Vincenzo

[ChristopheB]

Hi @DPrai.1​ ,

In case of VIN drops below VINOK_FALL threshold (PMIC turn OFF condition) but higher than VIN_POR_Fall threshold (and no time for software setting the Restart_request bit), then PMIC will go and stay in OFF state (waiting for a Turn On condition).

This is requested behavior of PMIC against bad power supply source.

BR,

Christophe

[MKim.18]

Hi @RBors.1​ , did you happen to figure out why the second scenario was causing the PMIC to enter a locked state?

[RBors.1]

ST published the AN5861 that should address the problems we encountered.

[GCici]

Hi,

maybe someone solved the problem by changing the CINTLDO capacitance value?