3.3V on Pin of Unpowered Raspberry Pi 4B

[vne147]

Hola ETO people!

I have a pretty basic question that I'm a little embarrassed I need to ask about. I'm not sure if this is the most appropriate forum, but here goes.

I'm currently working on a project where I have several Raspberry Pi 4Bs networked with one another. They communicate through ethernet, and I'd also like to use at least one GPIO to set a discreet enable/disable signal between the RPis.

My question: if I configure one RPi's GPIO as an output and connect it to a second RPi's GPIO configured as an input with internal pull up, then that line will be held at 3.3V even when the first RPi is unpowered. Is it safe to do this? I know that the RPi GPIOs are 3.3V tolerant but is that still the case even when it's unpowered?

At first thought I didn't think this would be an issue at all, but after a little thought I have seen many datasheets in the past where the absolute maximum voltage at a pin is defined in terms of VDD plus some value, say 0.3V. With the device unpowered, VDD is zero and 3.3V would far exceed that VDD + 0.3V. It seems that it's very difficult, I'm guessing to protect proprietary interests, to find detailed information about the microcontroller at the heart of the RPi. If I was using a PIC I'd have the answer in 30 seconds.

Anyway, I hope my question makes sense, and thank you in advance for any insight you can share.

 

[Nigel Goodwin]

Assuming the RPi has protection diodes on the inputs (like PIC's and most other micro-controllers do) then if you disconnect power to the processor while 3.3V is applied to an I/O pin then that 3.3V will flow through the top protection diode, and try and power the entire system. If you feed the I/O pinn via a series resistor, that will limit any possible current.

 

[vne147]

Assuming the RPi has protection diodes on the inputs (like PIC's and most other micro-controllers do) then if you disconnect power to the processor while 3.3V is applied to an I/O pin then that 3.3V will flow through the top protection diode, and try and power the entire system. If you feed the I/O pinn via a series resistor, that will limit any possible current.

Hmmm. That seems undesirable for my application. I don't want any sort of "back powering" even if I limit the current. I think I'll have to come up with another arrangement, maybe with some clever use of diodes or something along those lines. I'll give it a think.

Thanks, Nigel.

 

[Les Jones]

Why not just configure the GPIO pin as an input with the the internal pull up disabled. You can do this on most microcontrollers so I assume it is possible on a Raspberry Pi.

Les.

 

[Nigel Goodwin]

Why not just configure the GPIO pin as an input with the the internal pull up disabled. You can do this on most microcontrollers so I assume it is possible on a Raspberry Pi.

Les.

Disabling the pullup doesn't disable the protection diodes, and configuring as an input doesn't help as that's when the protection diodes are in use. Not to mention that presumably the Pi inputs don't maintain their settings when there's no power?.

 

[Les Jones]

My understanding of the first post is that Raspberry Pi with it's port configured as an input will be the one that remains powered on. Assuming this understanding of the situation is correct then even if the internal pull up resistors were enabled they would not provide enough current to damage the GPIO on the unpowered Raspberry Pi.

Les.

 

[tumbleweed]

It sounds like there are several boards involved here, so making sure that boards don't back-power other boards sounds like the best solution. Strange things can happen even if you limit the current.

 

[vne147]

My understanding of the first post is that Raspberry Pi with it's port configured as an input will be the one that remains powered on. Assuming this understanding of the situation is correct then even if the internal pull up resistors were enabled they would not provide enough current to damage the GPIO on the unpowered Raspberry Pi.

Les.

I didn't go into that much detail, but my specific application will be using multiple (up to 10) RPis all networked together. One of the RPis will be acting as the master and will set a discreet output signal to all other RPis to enable or disable the entire system. Because of design constraints I really can't go into, all RPis will need to use the same GPIO pin (set as output on the master and input on all others), and the GPIO pins on all the RPis will be bussed together.

My initial thought was to configure the GPIO on all the slaves as input with internal pullup, and configure the master's GPIO as an output. When I want the system to be enabled, I set the output high or floating. When I want the system to be disabled, I set the output of the master low, which will pull down the GPIOs on all the slaves.

This works great if everything is powered, but since all the GPIOs will be bussed, if one RPi get unpowered, it'll still see 3.3V on that pin which per the previous discussion is undesirable.

Another fly in the ointment is that whatever external circuit I come up with has to be generic. It will live on an external PCB connected to the RPi through the 40 pin header. The external board needs to be the same design regardless of whether the RPi it's connected to is configured as the master, or a slave.

I think I came up with a solution using 2 GPIO pins and a pair of diodes, but I'd be interested in any ideas you may have on how to skin this cat particularly if there is a single GPIO solution.

If my explanation wasn't clear I can upload a diagram to help.

Thanks.

 

[vne147]

It sounds like there are several boards involved here, so making sure that boards don't back-power other boards sounds like the best solution. Strange things can happen even if you limit the current.

That was my thinking too. I don't think simply limiting the current will be good enough. Any thought about how I can accomplish this?

 

[Pommie]

Could you use opto isolators. Power the LED from the master and use the output to pull a pin low on a slave.

Mike.

 

[vne147]

Could you use opto isolators. Power the LED from the master and use the output to pull a pin low on a slave.

Mike.

I sort of when down that rabbit hole already, but I couldn't figure out a way to connect the opto so it worked as required when the RPi was both a slave or the master. The external circuit connected to the RPi and the outside world has to be identical regardless of whether it's functioning as a master or slave. The only difference can be in the software and register settings.

My latest thought is I could possibly use voltage translator. Something like this SN74AUP1T34.

I think I could tie the VCCA, and VCCB pins to 3.3V on the RPi. So, if the RPi was unpowered, I could toggle 3.3V on the A pin all day long and the unpowered RPi's GPIO connected to pin B would never see it. I don't think it would damage the translator to have 3.3V applied to pin A and 0V on VCCA, at least a quick review of the datasheet didn't seem to indicate that.

I'm thinking adding a series resistor between B and the GPIO wouldn't hurt, but probably isn't strictly necessary.

There are also other translators out there with an EN pin like this one PI4ULS3V501TAEX. Not sure if it adds any value or not.

Thoughts?

 

[Pommie]

I don't like the name of that chip "1-bit Unidirectional Voltage-Level Translator" sounds one way. I'm assuming you can have software differences so maybe a bidirectional buffer with OE would suffice. Something like a 74245.

Mike.
Edit, I last used a 245 in the 80s!!!!

 

[rjenkinsgb]

How about this?

A common point with a low value pulldown resistor, eg. 1K or lower, whatever a Pi output can still pull up to full voltage.

Then from each Pi to that, a 100K resistor in parallel with a schottky diode.

The diode allows any Pi to pull the pin high when it is master; otherwise the Pi pin is an input with no internal pullup, so near zero load and the 100K has little effect - but no harmful current can ever be passed to a powered-off device, or between two powered devices that enable the output at the same time.

Ideally, have the 100K + diode combination close to the Pi it connects to, to keep the high impedance part as short as possible to minimise noise pickup.

 

[vne147]

I don't like the name of that chip "1-bit Unidirectional Voltage-Level Translator" sounds one way.

You're right. That was a mistake on my part. The SN74AUP1T34 won't work. What about the PI4ULS3V501TAEX?

Yes, I can have software differences. The 245 looks promising except for the direction control pin which could complicate things. I haven't really thought that through yet.

I also had another idea that just came to me. What about a triac with the gate connected to the 3.3V source of the RPi? I have very limited experience with them, so I'm not sure if it'd even work. I'd have to read up on their theory of operation.

How about this?

A common point with a low value pulldown resistor, eg. 1K or lower, whatever a Pi output can still pull up to full voltage.

Then from each Pi to that, a 100K resistor in parallel with a schottky diode.

The diode allows any Pi to pull the pin high when it is master; otherwise the Pi pin is an input with no internal pullup, so near zero load and the 100K has little effect - but no harmful current can ever be passed to a powered-off device, or between two powered devices that enable the output at the same time.

Ideally, have the 100K + diode combination close to the Pi it connects to, to keep the high impedance part as short as possible to minimise noise pickup.

This is an interesting idea. If I understand what you're proposing, I'd still be back-powering the unpowered RPi in the sense the unpowered GPIO would still see 3.3V, but the 100k resistor would limit the current so low nothing would result from it. Except for the addition of the schottky diode, it sounds similar to what Nigel proposed in post #2.

Does the schematic below accurately represent the idea?

 

[rjenkinsgb]

Does the schematic below accurately represent the idea?

Yes, assuming you also have a 100K and diode in line with every other connection to the 1K common point.
(And only the one "global" 1K pulldown).

An unpowered device should never see 3.3V, as it's input protection diode will pull the input down to not much over 0.6V, with only a few tens of microamps current flow, when another device sets its output high.

 

[Pommie]

An unpowered device should never see 3.3V, as it's input protection diode will pull the input down to not much over 0.6V, with only a few tens of microamps current flow, when another device sets its output high.

The diodes are arranged so that the pin can't go above supply voltage or below ground. So, the pin will see 3.3 - Vf of the diode. The 100k should stop the chip powering up so it shouldn't be a problem. Maybe a 1K resistor across the supply (of the unpowered pi) will reduce any voltage below the brown out voltage of the chip.

Mike.

 

[rjenkinsgb]

Just done an experiment and the inputs will go to near supply on an unpowered Pi even though fed through a 100K resistor! The Pi GPIO pins do not have input protection diodes...

To be 100% safe, add another schottky diode from the I/O pin to a 3.3V power pin, on each Pi connector.
That should guarantee no out-of-spec voltages appear.

 

[vne147]

Yes, assuming you also have a 100K and diode in line with every other connection to the 1K common point.
(And only the one "global" 1K pulldown).

I was planning on having an identical circuit on each RPi, including the pull down. The hardware needs to be identical. The only differences can be in software. I understand this means I'll have a whole bunch of pull down resistors in parallel, and I'll size them accordingly.

The diodes are arranged so that the pin can't go above supply voltage or below ground. So, the pin will see 3.3 - Vf of the diode. The 100k should stop the chip powering up so it shouldn't be a problem. Maybe a 1K resistor across the supply (of the unpowered pi) will reduce any voltage below the brown out voltage of the chip.

Mike.

I'm not sure I follow the 1k resistor bit. You mean connect a 1k resistor between 3.3V and GND on the RPi?

Just done an experiment and the inputs will go to near supply on an unpowered Pi even though fed through a 100K resistor! The Pi GPIO pins do not have input protection diodes...

Any ill effects from this test? I wish there was more detailed documentation on the RPi. It's very frustrating.

Just done an experiment and the inputs will go to near supply on an unpowered Pi even though fed through a 100K resistor! The Pi GPIO pins do not have input protection diodes...

To be 100% safe, add another schottky diode from the I/O pin to a 3.3V power pin, on each Pi connector.
That should guarantee no out-of-spec voltages appear.

So you're proposing adding another diode from the GPIO forward biased toward the supply to ensure the GPIO is never more than Vf above the supply voltage? That'll still drive the entire supply bus up to nearly 3.3V and "back power" it. Still nothing should happen with the 100k resistor limiting current, and with the added diode now at least it'll prevent the GPIO from going far above the supply, but I feel like we're back to square one accepting that portions of the unpowered RPi will be driven up to 3.3V.

I still don't really like it. I'd prefer to incorporate a solution with completely known behavior, minimizing the times I have to say something like "it should be OK".

I feel like I'm overcomplicating things and this is something that was figured out sometime in the 70s.

I'm going to have a closer look at some of those buffer IC options.

 

[Pommie]

I'm not sure I follow the 1k resistor bit. You mean connect a 1k resistor between 3.3V and GND on the RPi?

Yes, the idea being that a 1k resistor will provide a suitable load to stop the supply voltage from getting above the brown out voltage of the CPU (anyone know what the BOV is?) and prevent it being "back powered"

Mike.

 

[Pommie]

BTW, to have identical boards means repeating the circuit for however many PIs you have on every PI. Assuming each slave will listen on a different pin and the master will output on many pins to address each slave. Seems excessive.

Could there be a software solution so that you send all communication to all PIs with an address identifying which PI it's for?

Mike.