Prevent PMIC_STBY_REQ = 1 after poweroff

[borgestrand-ber]

Hi, 

I'm working on an IMX6SL design. I have a power management question. After powering down in u-boot I see that PMIC_ON_REQ goes down almost immediately after writing to the TOP bit. The ONOFF pad remains high. While powering down there is no other input to the SNVS sub-system other than setting bits 0, 5 and 6 of SNVS_LPCR. 

However, some 10.4ms later, PMIC_STBY_REQ goes high. This brings the PMIC (PF0100) into standby mode. I am able to prevent the PMIC from outputting supply voltages in this mode, that is not the issue. The problem is that it consumes too much power in standby mode, and disables standby from being used properly in other places of the design.

So: How do I prevent PMIC_STBY_REQ from being set high during a power-off event?

Should I touch VSTBY or STBY_COUNT in CCM_CLPCR?

Best,

Børge 

Henry Audio

[art]

So far, I haven't found a way to prevent PMIC_STBY_REQ from going High when PMIC_ON_REQ goes Low. The gap between PMIC_ON_REQ negation and PMIC_STBY_REQ assertion seems to be related somehow with the CCM_CLPCR[STBY_COUNT] counter, let me check it once again. The PMIC_STBY_REQ assertion when PMIC_ON_REQ is Low does not affect the PMIC operation and does not cause any extra current consumption by the PMIC, since all the PMIC power supplies (that typically consume most of the current) are off due to the fact that PMIC_ON_REQ is Low. The early processor wake-up may be caused by some external event e.g. a tamper event detection. I have checked it on my i.MX6SL EVK board as well, and it never occurs. Also, during the regular operation, when the system goes to some low power (but not completely Off) mode, the PMIC_STBY_REQ signal goes High, causing the PMIC to drop the supply voltages according to the Standby mode settings. In the same time, PMIC_ON_REQ remains High as expected.

What is the reason of absolutely preventing PMIC_STBY_REQ from going High when PMIC_ON_REQ is low if it does not affect the system operation? Does it affect your design in any other way?

Best Regards,

Artur

[borgestrand-ber]

Hi Artur, 

I have tried CCM_CLPCR = 0x00000079 and 0x00000379. Both cases give the same 11ms timeout between clearing PMIC_ON_REQ and setting PMIC_STBY_REQ. 

Are you aware of registers settings which will cause PMIC_ON_REQ to be asserted alongside PMIC_STBY_REQ? 

Best regards,

Børge

[art]

Dear Borge,

So far, I've measured the delay between PMIC_ON_REQ negation and PMIC_STBY_REQ assertion when going to the power off mode on various boards I have (i.MX6SL EVK, i.MX6Quad SABRE SD, i.MX6SoloX SABRE SD) under various Linux builds control. All measurements gave me near the same results of around 2.0ms (slightly vary form item to item). Unfortunately, still have no idea abou the register settings (if any) that may control this delay. I can escalate your request to the R&D team and ask them to check if required.

Best Regards,

Artur

[art]

Actually, still not sure about register settings. Will spend some more time to make some more tests on my i.MX6SL EVK hardware. Will be back to you as soon as I get some definite results.

Best Regards,

Artur

[borgestrand-ber]

Hi Artur, 

Thank you for your response! I will check CCM_CLPCR when I'm back in the lab. 

This has been a learning experience, and I now realize we don't strictly need to prevent PMIC_STBY_REQ from going high after a poweroff. 

However, we do see PMIC_ON_REQ going on with PMIC_STBY_REQ (or very shortly thereafter), in some of the

poweroff cases. See pictures below of the whole progression and a zoom-in. 

After a power-cycle and boot into u-boot, PMIC_ON_REQ goes high at each poweroff(). If I warm-boot into Linux once, all subsequent poweroff() events in u-boot will NOT cause PMIC_ON_REQ to go high. This makes me believe that whether or not PMIC_ON_REQ will be asserted along with PMIC_STBY_REQ, is set in some register which is reset by a power cycle and not by POR_B. We're seeking further details on how our SW can influence this. 

Best regards, 

Børge

[borgestrand-ber]

We run both u-boot and Linux on the same hardware, and I strongly suspect there is some software setting I have overlooked. 

In u-boot the time from a poweroff with PMIC_ON_REQ going down to PMIC_STBY_REQ going up on its own is +-11ms. In Linux it is +-8ms. This makes me think there is a programmable timer or countdown. The measurements may indicate that an unprecise timer is initiated the same way each time in u-boot and consistently with a different value in Linux.

In u-boot, for the first time after a hard power cycle, both PMIC_ON_REQ and PMIC_STBY_REQ go up 11ms after a poweroff. But if I boot Linux in the mean time and do a soft power cycle, only PMIC_STBY_REQ goes up after 11ms. This makes me believe there is a setting which differentiates between poweroff and reboot.

Could you please help me locate registers which may influence this so that I know where to look in the code? I need to copy code from Linux to u-boot, but which code? With your help the search will be limited.

Thanks,

Børge

[borgestrand-ber]

This means I'm looking for two things:

a) How to set a timeout for the period from PMIC_ON_REQ \/ to PMIC_STBY_REQ /\

b) How to configure a write to TOP = 1 to mean poweroff or reboot. This setting seems to survive a low POR_B

Best,

Børge

[borgestrand-ber]

... but  b) does not survive a power cycle. The default setting of this configuration after a power cycle will cause PMIC_ON_REQ to go high with PMIC_STBY_REQ.

Børge

[art]

Dear Borge Strand-Bergesen,

Actually, this is just the expected behaviour. As per the PF0100 PMIC operation logic, the PMIC_STBY_REQ signal (STANBY signal on the PMIC side) is only valid when the PMIC_ON_REQ signal (PWRON signal on the PMIC side) is High. I.e. when PMIC_ON_REQ is High and PMIC_STBY_REQ is Low, PMIC outputs the Run mode supply voltages, when both signals are High, PMIC outputs the Standby mode supply voltages. Once PMIC_ON_REQ goes Low, PMIC goes to the Off mode regardless of the PMIC_STBY_REQ state. If the VDD_SNVS_IN voltage is constantly present to the processor, it is possible to switch the whole system back to Run mode by pulling the processor's ONOFF input Low for more than 750ms but less than 5s. It makes the SNVS domain logic to put PMIC_ON_REQ High and PMIC_STBY_REQ Low, thus, switching the PMIC back to Run mode.

Best Regards,
Artur

[borgestrand-ber]

Hi Artur,

Thank you for the details. Please see the pictures above.

Based on the information available to you, which mechanisms can possibly set PMIC_STBY_REQ high while POR_B is low?

What baffles me is that PMIC_STBY_REQ is brought high approx. 11 ms after PMIC_ON_REQ is brought low. I don't know if it is PMIC_ON_REQ going low, or POR_B going low, which causes the CPU to eventually set PMIC_STBY_REQ high. Either way, I'd very much like to keep PMIC_STBY_REQ low at all times (except when I deliberately put it into STOP mode in code).

The 11ms delay time increases slightly with increased VBAT. Supplying 3.8, 4.05 and 4.3V, give average (over 6 measurements each) delays of 10.6738, 10.8635 and 10.9063ms, respectively. I find this strange. VBAT is the input to various regulators in the PMIC, but not in the CPU. 

In my measurements, PMIC_STBY_REQ always goes high about 11ms after a poweroff (=write to TOP bit = 1). Some times, but not every time, PMIC_ON_REQ will also go high approx. 80µs after PMIC_STBY_REQ. Either way, POR_B is low while these events happen.

When only PMIC_STBY_REQ goes high, total power consumption is comparable to PMIC standby current. It is well worth it to reduce this. When PMIC_ON_REQ also goes high, the system reboots. I'd like to avoid that.

In the system, ONOFF of the CPU is connected to a button to GND with internal pull-up (IMX6SLRM.pdf page 2750, Figure 46-1.) POR_B, PMIC_ON_REQ and PMIC_STBY_REQ are connected to the PMIC like on figure 46-2.

Best regards, 

Børge

[borgestrand-ber]

Also, we have experimented with both setting and clearing the VSTBY bit before writing 1 to the TOP bit. 

Modifying VSTBY does not change the way the poweroff sequence works. PMIC_STBY_REQ is set 11ms later each time. 

Best regards, 

Børge

[borgestrand-ber]

Perhaps this may clarify things: When I read from SNVS_LPCR I get 0x0..021, indicating that "Security-related field 0" is set. This field is not documented in the datasheet. Do you have access to information about why it is set?

Thanks,

Børge

[art]

This security-related field is described in the i.MX6SL Security Reference Manual document, available for download request on the processor's Documentation web page (check the "Reference Manual" section):

https://www.nxp.com/products/processors-and-microcontrollers/applications-processors/i.mx-applicatio...

However, this field has no any relation with power management.

Best Regards,
Artur

[borgestrand-ber]

Hi Jose, 

1) In our system, VIN is present at the PMIC all the time, and VSNVS is present to the CPU at all time. We'd honestly like the PMIC_STBY_REQ to not function at all, over this functionality where it goes high while POR_B is low. 

2) We see that PMIC_STBY_REQ is low before a poweroff is issued, and stays low while PMIC_ON_REQ goes low. At this time an active high STANDBY pin into the PMIC serves our purposes well. However, 10.4ms after PMIC_ON_REQ and POR_B go low, PMIC_STBY_REQ goes high. Immediately after that, PMIC_ON_REQ goes high. These are the transitions we wish to avoid. I don't rule out that we could put in some hack with inverted STANDBY polarity, but that would be counterproductive for the 10.4ms after we surrender software control. 

Please see the attached images. REF_CLK_24M is the PMIC _INT pin. ONOFF is the active low button. The first image is of a boot process where poweroff is dirty, and the CPU restarts. The second image is of a clean powerof without restart. 

But even with the clean poweroff, we suspect the PMIC is held in STANDBY mode due to PMIC_STBY_REQ = 1. Our aim is to have PMIC_STBY_REQ a static 0 during the whole process.

Best regards, 

Børge

[borgestrand-ber]

Hi Jose, 

Thanks for your answer. 

We're trying to prevent PMIC_STBY_REQ from going high. In the system, the following happens:

VIN = Li Ion battery constantly connected. At the time being it's a 4.2VDC lab supply. The SNVS supply does not have a coin cell available. 

ONOFF = button to GND, pulled up to VSNVS internally in the CPU. We're not touching this signal.

The software-controlled poweroff is a write to the TOP bit. We see PMIC_ON_REQ go low after that. About 95µs later, POR_B is pulled low by the PMIC. So far so good. At this stage we want all supplies to be turned off, and nothing to happen until we pull the CPU ONOFF sigal low with a button.

However, 10.4ms after POR_B goes low, PMIC_STBY_REQ goes high. I haven't yet found any other intervening events. PMIC_STBY_REQ going high makes the PMIC output the standby voltages. Just after that, (standby) supplies are established, and the CPU pulls PMIC_ON_REQ up. With fully present supply voltages, the PMIC takes POR_B high. This completes an undesired boot loop.

We tried a hack: Configuring the PMIC to turn off all supplies in standby mode. That works, but PMIC_STBY_REQ still goes up 10.4ms after POR_B goes low, and the system consumes too much idle current. We suspect that this current is burned in the PMIC. 

From the observations I see two things I could call state machine bugs, or at least things I don't understand:

1) With POR_B static low, how can any part of the CPU do anything, like setting PMIC_STBY_REQ?

2) With PMIC_ON_REQ static low, how can the PMIC respond to a positive edge in PMIC_STBY_REQ and turn standby mode voltages on?

The ideal solution to this would be to prevent the CPU from setting PMIC_STBY_REQ outside of the software deliberately putting it in stop mode. The automatic assertion of PMIC_STBY_REQ is quite a bother. 

But if we can modify the PF0100 behavior, that would be nice too. 

Thanks,

Børge

[reyes]

Hi Børge,

The SNVS supply does not have a coin cell available, but how is VDD_SNVS_IN? This is important because PMIC_STBY_REQ is a push-pull output referenced to VDD_SNVS_IN, so VDD_SNVS_IN must be present for this pin to function.

2.

From the PMIC point of view, the only thing that you can modify related to the PMIC_STBY_REQ behavior is that the STANDBY pin of the PMIC can be configured as active high or active low using the STANDBYINV bit. To change the STANDBY pin polarity to Active Low, set the STANDBYINV bit via software first, and then change the regulator settings for Standby mode as required. This may help to prevent the PMIC to go to STANDBY mode.

I hope this helps.

Have a great day,
Jose

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[reyes]

Hi,

This is a normal behavior since the PMIC_STBY_REQ signal is controlled by the SNVS module that is located in separate VDD_SNVS power domain and whose state is not affected by the POR_B signal.

PMIC_STBY_REQ is a push-pull output referenced to VDD_SNVS_IN (always ON), so VDD_SNVS_IN must be present for this pin to function.

PMIC_STBY_REQ should be directly connected to the STANDBY pin of the MMPF0100 without the need of an external pull-up resistor.

What is the voltage at VIN? When operating the PMIC at VIN ≤ 2.85 V and VSNVS is programmed for a 3.0 V output, a coin cell must be present to provide VSNVS, or the PMIC does not reliably enter and exit the STANDBY mode.

The way to put the PMIC_STBY_REQ signal to Low is to power-cycle the VDD_SNVS_IN power rail (that means the complete power-cycling of the processor since VDD_SNVS_IN must be always powered on first and switched off last) or to push the ONOFF button (set the ONOFF input of the processor Low for greater than 750ms but no longer than 5s).

Have a great day,
Jose

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[borgestrand-ber]

I believe the core of the matter is that PMIC_STBY_REQ goes high 10.4ms after POR_B goes low. 

What could be the causes of that?

Best regards, 

Børge