Self-latching auto shutdown circuit

[teotwaki]

Hi all,

I know, this is something that has been discussed a few times. However, the typically recommended LTC2955 is a tad pricey at the moment, so I'm trying to cut down on costs a bit. I was wondering if anyone could provide some input on the attached schematic. I have watched Dave's video from a few years ago about the jelly-bean parts, however it focuses on single latching button/flip flopping. I don't think I've invented this design, but I also can't remember where I saw it.

Objectives:

• Reduce power consumption when system is inactive. The uC will shut itself down after 20-30 minutes of inactivity.
• Single momentary switch input to turn and latch on the system. The uC takes a while to boot, so waiting for it to go high on one of its GPIOs is quite annoying/counter productive.
• Handle between 10-30V power input.
• Don't turn on the system when power is applied (wait for button press).
• Use currently available components (hence the use of the AO3401 and UMH3N.

Behaviour (or at least, my understanding of the behaviour):

• When power is applied, the FET is off due to Vgs being 0
• When button is pressed, FET switches on and powers the uC due to Vgs = -Vbat
• When the FET is on, Vbe on Q3B is high enough to saturate it, pulling the gate on the FET to GND and latching the circuit on.
• When the uC drives GPIO_SHUTDOWN high, the gate of Q3B is pulled to GND, which means Vgs falls to 0, interrupting the circuit.

Questions:

• Would this work at all? Am I massively oversimplifying and being a complete idiot?
• How/what would you improve?
• If there's an easy way to implement "Hold (10s) button for forced shut off", I'd be happy to hear it. (this is purely optional, though)
• Is there any chance that if GPIO_SHUTDOWN pulses high/low during uC shutdown that it "restarts"? Should I add an C between GPIO_SHUTDOWN and GND to filter it out?
• Is R3 too big? I'm not sure I understand the UMH3N datasheet on how much Ib is necessary to fully saturate it.

[Bravo]

I tested this on Proteus simulation. I made the base resistors 10K & the battery volts 5v & it worked fine.
I did not have the same P ch FET as you have though. I was using an IRLML6401.

[DavidAlfa]

There's a big issue in your circuit:
When the voltage falls below working range, the mcu will enter reset state, setting all pins in High-Z.
Now you no longer have control of your shutdown pin.
Q3B will work down to 0.6V, so in the instant the mcu stops, it will enable Q2 again.

Anyways, you must take in count that using this method, if the switch is accidentally kept pressed, the power will be never removed, as it permanently forces Q1 on.

You really need something that forces the off-state when the mcu is not running.
How many does a mcu need to boot up the most basic init, setting gpios, etc? Usually it takes few milliseconds.
This circuit makes a temporal latching, about 400ms. After that, Q3 will force shutdown.
Within this time, the mcu must do at least some basic GPIO initialization, pulling SHUTDOWN pin to ground to prevent Q3 from turning Q2/Q1 off.
R2/C3 make a RC circuit, so you should calculate how much time it takes for C3 to get charged to 0.6V, this example is for 3.3V VDD.
MCP1702 is just as example, representing your VDD rail.

You can read the button at any time, and keep track of the state.
Now if you detect it was pushed down for 10s, just trigger shutdown action, in the moment the button is released the power will be turned off.

You must set shutdown high to power off the circuit.
C3 will get charged, in the instant it reaches 0.6V,  Q3 will turn off the other transistors.
When the MCU resets by low voltage, R2 will keep Q3 on until it discharges completely.

[Peabody]

I would just question why you believe the processor would take too long to boot up after you've pressed the button.  I think typically you would be unable to press the button briefly enough that the processor wouldn't boot fast enough to keep itself powered up.  If that isn't really an issue, you could eliminate one transistor, and an active high output on the GPIO pin would be required to keep power on, which means as the MCU goes into reset, power would not turn back on.

If the circuit turns on when you first connect power, try adding a small capacitor between the source and the gate.  That will make the gate come up with the source, so Vgs stays near zero as the voltage rises.

[teotwaki]

Hi David,

Many thanks for the very detailed response(s) you've written up and the time you're spending on this. Much appreciated! This is fantastic circuit and feedback you've given me. I hadn't considered the high Z state during shut down at all.

Peabody, the reason why I was attracted to the self-latching is because this is booting up a Raspberry Pi, and I'm not exactly sure how long it would take before it is able to take control over the GPIOs. As far as I can tell from some preliminary research, this is something that can take many seconds (if we presume I will configure the pin as low from the userland)*.

I was hoping to use the gpio-poweroff overlay as the shutdown line:

Name:   gpio-poweroff
Info:   Drives a GPIO high or low on poweroff (including halt). Using this
        overlay interferes with the normal power-down sequence, preventing the
        kernel from resetting the SoC (a necessary step in a normal power-off
        or reboot). This also disables the ability to trigger a boot by driving
        GPIO3 low.

        The GPIO starts in an inactive state. At poweroff time it is driven
        active for 100ms, then inactive for 100ms, then active again. It is
        safe to remove the power at any point after the initial activation of
        the GPIO.

        Users of this overlay are required to provide an external mechanism to
        switch off the power supply when signalled - failure to do so results
        in a kernel BUG, increased power consumption and undefined behaviour.

The overlay, in combination with the auto-off circuit, basically allows me to treat the Raspberry Pi as having a "proper" power supply. Meaning that the power supply would be cut off after the system has finished shutting down properly.

*: I know it is possible to use

gpio=x=op,dl

in config.txt to drive the pin low, however it appears this is only during part of the boot process, and the pins would be reset to input during initialisiation.

[porter]

FYI, Here is the power-up circuit from the transistor tester project.

[DavidAlfa]

Please specify all these details from the beginning
MCU and linux system are completely different things.
This is a double latch:
- On poweron (When the button is pressed down), it latches.
- When shutdown is pulled to gnd for at least ~200uS, poweroff latch will be trigered, cancelling the first latch.

[teotwaki]

Hi David,

Thank you very much for your help. This indeed makes a lot of sense. I apologise for not being clearer about the entire project from the get go.

[nikifena]

I had the same problem in the past, so I did a research, and also I tested a few design ideas
Here is what works for me. It has a few benefits.
- the button acts as a power on and as a button for doing something for the device – a dual function
- you don't need to press and hold the button to power the unit on. It turns on by a quick press

 
Both PW ON and SW1 signals go to the processor.

[DavidAlfa]

The power won't be latched until the rPi takes control of the pin and enables POWERON.
That's the issue mentioend earlier, the system will need several seconds to boot and enable the power.

[nikifena]

That's the function of C18.
If you want more time, just increase the value

[teotwaki]

Here is what works for me. It has a few benefits.

Thanks for sharing nikifena. It looks like a simple design indeed. I'll look at this over the coming days.

This is a double latch:

Am I correct in understanding that as long as Q2 is latched, /BUTTON will be active?

In any case, as the re-use of the button was optional, I ended up with the following, closely inspired by your design, see attached.

As you can probably tell, I'm trying to protect the Vgs rating of the pFET, but not entirely sure how to do it. The simulations appear to indicate the current design would work, but if anyone has a better approach, or sees major issues, I'm happy to learn.

[DavidAlfa]

You're right!  Another diode will solve that.
The zener is placement wrong, does nothing, Q2 will pull the gate to gnd in the same way.
Check 2nd picture for correct way!.

[uer166]

I had the same problem in the past, so I did a research, and also I tested a few design ideas
Here is what works for me. It has a few benefits.
- the button acts as a power on and as a button for doing something for the device – a dual function
- you don't need to press and hold the button to power the unit on. It turns on by a quick press

 
Both PW ON and SW1 signals go to the processor.

Can confirm I've done this (almost exact same circuit) with success. In my case the FW booted fast enough to not need that gate cap. It has a great advantage in that you can re-use the button as a user button, as well as a power-on button. And for shut-down the FW simply shuts down the GPIO and commits suicide.

[Andreas]

• Handle between 10-30V power input.

• When button is pressed, FET switches on and powers the uC due to Vgs = -Vbat

Hello,

the poor AO3401 is only specified for -12V gate source voltage not for -30.

with best regards

Andreas

[teotwaki]

the poor AO3401 is only specified for -12V gate source voltage not for -30.

Thanks Andreas, I switched to a different PFET which has a max Vgs of +/- 20, and added a 12V zener to protect it.

The zener is placement wrong, does nothing, Q2 will pull the gate to gnd in the same way.

I had something working in my sim, and then completely mucked it up while copying it over to KiCad prior to posting it here. This is a good lesson that I shouldn't try to do this past midnight.

So, combining both your suggestions, I came up with the following (see attached), which appears to be working in sim.

• At startup, Vgs = 30V, Q1B is off
• When J2 is pressed, Q1B turns on, Q2 and Q4 also turn on, latching the system, GPIO_BUTTON is at 2.7V (which I presume is 3.3V - D3's Vd)
• With system on, when J2 is pressed, Q1B is unaffected, and GPIO_BUTTON goes down to 0V

Again, happy to be educated if I did anything wrong.

[Peabody]

I would just go back to question #4 in your original post about a possible rebound when you shut down.  As the 3.3V rail  begins to fall, it's not clear how the bipolars will respond.  And GPIO_SHUTDOWN will at some point become tristate.  It seems it would be better for GPIO_SHUTDOWN to have to be high for power to be on.  Well, it may work fine.  Just need to test thoroughly.