Multiple uCs/GPIO devices to single mosfet gate; Goal to shut down RPi cleanly

[mortrek]

My goal is to have a uC power up a Raspberry pi with a MOSFET, and have the RPi take over the MOSFET control by also wiring it into the same gate so that it can decide when to power itself down.

Basically, uC sets MOSFET gate to high, turning on RPi. RPi sets its GPIO leading to the gate to high on boot. Even if uC's output goes low, the MOSFET stays high, keeping itself on. RPi does some stuff which takes an indeterminate amount of time. RPi is told to shut down, and shutdown script turns GPIO to gate OFF after doing all housekeeping/unmounting, thus shutting itself down cleanly.

Does this work? And do I need to include diodes to protect the IOs from each other? Or caps to maintain a clean signal? Anything else wrong with this?

[Ian.M]

Nope.

You need the MOSFET to be a high side switch (i.e. in the positive side of the supply, not the ground) so either you need a P-MOSFET, which needs its gate pulled low to turn it on, or if you use a N-MOSFET, you need a gate drive supply that's significantly above the 5V rail the MOSFET is controlling.

However once you use a P-MOSFET, with a gate pullup resistor to keep it off, any number of transistors or switches can be used to pull the gate low to turn it on, and it wont turn off till they all stop pulling it low.  Be careful of ICs with open drain outputs - if they have a protection diode to Vcc they will pull down the gate if their Vcc supply goes away!

I/O pins and blocking diodes directly driving the MOSFET gate aren't a great idea as most MCUs have internal protection diodes so an un-powered I/O pin will drag down gate, turning the MOSFET back on, resulting in oscillation or a possibly half-powered state that may burn out the MOSFET.

N.B. later model PI B's have a smart power switching chip (or a PMIC) controlling power to the USB ports.  USB Vbus switches on fairly early in the bootup process and is switched off very close to the end of the normal shutdown sequence.   If you've got a PI that does this, you don't need to waste a GPIO for power control, just use Vbus with maybe a second or two delay, to give the startup sequence time to turn on Vbus, and to complete shutdown.

[mortrek]

Seeing as how I'm a newbie, could you explain why I need to use a high-side switch? I'm currently using an NPN on the ground side of a circuit driven by a 3.5-5.0V voltage at the gate, with the voltage of the device switched at more like 9V, and it works very well. Is it because I want to use more than one driver for the gate?

[ggchab]

Instead of controlling the MOSFET with the RPi, why not using that line to communicate with the µC that would then be the only device controlling the MOSFET ? Just a suggestion. I don't know if this can work with what you want to do.

[Ian.M]

Why high side switch?

A low side switch is fine for 'dumb' loads or if the load doesn't have wired connections to any other devices, but is problematic for smart loads with external connections.

Lets take your example of a NPN transistor switching the ground of a load powered from 9V, e.g. an Arduino.  When the transistor is off, the Arduino Gnd (0V) rail will be up near 9V, as will any signals connected to Arduino I/O pins *AND* the ground and shell of the Arduino USB connector.  If those signal lines go to logic chips using the same 0V rail as the emitter of the switching transistor (and the 9V PSU 0v) they probably wont be very happy as the Arduino will attempt to drag  their inputs or outputs high, above the logic Vcc supply if its less than 9V, and power up via the ATmega328P I/O pin lower protection diodes.  Odds are it may exceed the logic and ATmega328P I/O pin current ratings, with a significant risk of damage both to the logic and the Arduino.  Also, if the 9V supply is ground referenced, plugging a USB lead into the Arduino will power it up if the other end is connected to anything grounded, (even a PC that's switched off!), as the 9V PSU 0V return current can bypass the switching transistor via the USB lead shield and the mains wiring ground between the USB host and the 9V PSU.

OTOH if you use a high side switch, all 0V/grounds in the system stay firmly tied together at the same level, It doesn't randomly power up when you plug in external connections, and the only constraints on interconnections to the switched device are that you mustn't try to drive a logic '1' into  any I/O while its off.

[mortrek]

Instead of controlling the MOSFET with the RPi, why not using that line to communicate with the µC that would then be the only device controlling the MOSFET ? Just a suggestion. I don't know if this can work with what you want to do.

Actually this may work fine. I thought I was being clever and came up with some sort of elegant solution to the problem, but I guess not. Your solution is just about as good and it probably actually works I don't think using a PNP MOSFET will work for me in my case. I really need uC HIGH=ON for the controlled circuit, and I need it to be barebones (fewest quiescent currents to worry about) to keep power consumption down.

Even just a digital out to digital in line would probably be fine, with some filtering/debouncing type stuff. I don't want to use up a serial line for something so simple. Only problem is the uC and RPi may be at slightly different logic levels...


any idea if you can put up to ~4.5V uC digital output into a 3.3V RPi GPIO without causing damage? Very small currents of course, and RPi has pretty high input impedance right?

I ask of course because the uC will nominally be operating at about 4.5V, down to maybe 3.3V minimum, but it likely will never get to that low voltage during its use.

I run the uC (just an ATMega328p at 1MHz to do basic coordination) off 3 alkalines with no regulator (probably sounds stupid...) but I do it because I need it to run a very long time and even efficient regulators have quiescent currents that become a big deal over a long time. So far (1+ years) it's worked great on a single set of batteries.

Basically the whole thing will be running off batteries and I can't really have the RPi on very long, but I really don't want to corrupt the filesystem and the work it does is somewhat indeterminate/variable, so I need some sort of more precise control to shut it down exactly when it's ready. A simple "shut down now" input line sounds fine. Shutting down the RPi does not shut down connected HATs since the power just seems to get passed through, so even if the RPi shuts itself down, it doesn't do me much good.

I have a set of 3 alkaline batteries for the uC and a separate set of 8 D alkalines for the rest of the stuff, making a ~12V nominal supply with a regulator producing a 9V rail for one device and a 5V rail for the RPi. The circuit should be happy with 1.1V cutoff (so 8.8V) assuming the batteries can still output a bit of current. I already have essentially the same project working without the RPi, and it works well, so this is sort of the "Version 2" of it, where the RPi is necessary for higher-level stuff.

This will need to be able to be set up in a remote location and work consistently for about a year. Again, the "Version 1" has worked great and I'm at about 400 days now.

Thank you everyone for your input.

edit: Looking around, it does appear that you cannot use higher voltages w/RPi GPIO without damage, so a level shifter or voltage divider must be used. That's fine, since the uC keeps its voltage probably above 3.6V anyway, and the GPIO on the RPi seems to require >2.3V, so using a simple divider may be fine to get it down a bit...

[mortrek]

What if you isolate the gate control lines with something like an optocoupler? Would that help keep the N-channel MOSFET w/o major problems? For various reasons I'd like to keep using it and not a P-channel MOSFET.

[Ian.M]

Nope.  Its the switch that separates load 0V from supply 0V that causes the issues, not how that switch is controlled.  It *can* be made to work if the supply is fully floating with absolutely no possibility of it becoming ground referenced, which in practical terms usually means a battery pack with absolutely no way of charging it in-situ, provided you take care of the level shifts on signal lines between the switch on and off states, e.g. by optoisolation.

However its a right PITA to do compared to the easy option of a power P-MOSFET with a gate pullup (default off), and as many signal N-MOSFETs as you have control signals connected to pull down its gate to turn it on.  The off state quiescent current is near zero, as its only the total leakage current through the off-state MOSFETs.  The on state quiescent current is higher, (set by the P-MOSFET gate pullup resistor) but is usually negligible compared to the load's quiescent current.

The other option is a N-MOSFET high side switch, but to switch a 5V supply, that will need about 10V on the gate to turn it on if you are  using a logic level drive MOSFET or about 15V for an ordinary one, which is usually far from convenient due to the need for a gate drive supply well above the power rail being switched, and a gate driver that can provide a 10V or 15V output swing controlled by a logic signal.   Its generally not worth it except for very high current loads where the lower Rds_on of a N-MOSFET (compared to a P-MOSFET of similar size and geometry) can save enough on I²R losses and thus heatsinking to make up for the extra cost and complexity of the driver

[T3sl4co1l]

Absolutely.  Put a R-S latch on the gate.  MCU sets it, it stays on.  rPi comes up, its output stays inactive, it doesn't need to do anything.  When shutdown occurs, it resets the latch, turning itself off.

Tim

[mortrek]

Nope.  Its the switch that separates load 0V from supply 0V that causes the issues, not how that switch is controlled.  It *can* be made to work if the supply is fully floating with absolutely no possibility of it becoming ground referenced, which in practical terms usually means a battery pack with absolutely no way of charging it in-situ, provided you take care of the level shifts on signal lines between the switch on and off states, e.g. by optoisolation.

However its a right PITA to do compared to the easy option of a power P-MOSFET with a gate pullup (default off), and as many signal N-MOSFETs as you have control signals connected to pull down its gate to turn it on.  The off state quiescent current is near zero, as its only the total leakage current through the off-state MOSFETs.  The on state quiescent current is higher, (set by the P-MOSFET gate pullup resistor) but is usually negligible compared to the load's quiescent current.

It is exclusively run on primaries. Never charged, never ground-referenced. I'm designing it to run a minimum of 1 year on alkaline primaries.

A P pulled up with Ns as the controllers seems like a lot of added components and complexity for this, but if it would work, it's an option. On quiescent currents don't make a huge difference compared to off currents.

Do you see any issues with the RPi communicating with the uC to tell it when to shut it off? Of course the logic levels are different, but that can be fixed with a logic level converter or voltage divider or whatever I imagine. I'd like to keep this as simple as possible from a circuit and component level.

[mortrek]

Absolutely.  Put a R-S latch on the gate.  MCU sets it, it stays on.  rPi comes up, its output stays inactive, it doesn't need to do anything.  When shutdown occurs, it resets the latch, turning itself off.

Tim

This seems like a great idea. It won't cause any other problems to use one as the gate driver, with two different devices connected to SET and RESET? All devices are run from batteries. I've used N-MOSFETs so far with no trouble in a similar configuration, just not with two inputs.Do they even make single R-S latches or are they all quad?

[T3sl4co1l]

If nothing else you can use a 74HC2G02 or the like to construct the latch.  A pair of transistors (or a few more) can do it as well, or even using the active transistor as part, depending on how much bias current and layout area you can afford.

Tim

[Ian.M]

Do you see any issues with the RPi communicating with the uC to tell it when to shut it off? Of course the logic levels are different, but that can be fixed with a logic level converter or voltage divider or whatever I imagine. I'd like to keep this as simple as possible from a circuit and component level.

It depends on the 5V uC's input thresholds - if they are TTL compatible you can drive it direct from 3.3V logic like the Pi GPIOs, but if they are normal CMOS thresholds, logic '1' will be marginal and you'll need a level shifter for reliability.  I favour 74LVC1T45 single gate and '2T45 dual gate bidirectional buffers for that because they can handle any logic levels between below 1.8V and 5.5V, have decent drive capabilities and are guaranteed to tristate on partial power-down.  Strap the direction pin high or low as required when you only need single direction logic level translation.

Beware of any 5V level logic signals going to Pi GPIOs.  You can use potential dividers for downwards level shifting, but they are power hungry if the usual state is logic '1', so it may be worth using a proper level translator.