rownyr
Posts: 41
Joined: Wed Jul 11, 2012 1:25 am

GPIO initial state

Sun Jun 23, 2013 8:43 pm

Hello,

I have some GPIO pins connected to power MOSFET gates. Controlling these from the C program works as expected, however I have found a serious problem. During the first 1-2 seconds after powering-on the Pi, these gates are driven by 3V potential, effectively turning the MOSFETs on. After this time the gates are turned off (GPIOs are set to low level).

Is there a way to fix the output of these GPIOs to always remain at low level, even at the power-on?

User avatar
aTao
Posts: 1087
Joined: Wed Dec 12, 2012 10:41 am
Location: Howlin Eigg

Re: GPIO initial state

Sun Jun 23, 2013 9:42 pm

rownyr wrote:Hello,

I have some GPIO pins connected to power MOSFET gates. Controlling these from the C program works as expected, however I have found a serious problem. During the first 1-2 seconds after powering-on the Pi, these gates are driven by 3V potential, effectively turning the MOSFETs on. After this time the gates are turned off (GPIOs are set to low level).

Is there a way to fix the output of these GPIOs to always remain at low level, even at the power-on?
Short answer is no, you should switch the RPi on, let it settle and then apply power to your external circuit.
>)))'><'(((<

rownyr
Posts: 41
Joined: Wed Jul 11, 2012 1:25 am

Re: GPIO initial state

Sun Jun 23, 2013 10:13 pm

aTao wrote:
rownyr wrote:Hello,

I have some GPIO pins connected to power MOSFET gates. Controlling these from the C program works as expected, however I have found a serious problem. During the first 1-2 seconds after powering-on the Pi, these gates are driven by 3V potential, effectively turning the MOSFETs on. After this time the gates are turned off (GPIOs are set to low level).

Is there a way to fix the output of these GPIOs to always remain at low level, even at the power-on?
Short answer is no, you should switch the RPi on, let it settle and then apply power to your external circuit.
But I'm applying power using GPIOs... Turning MOSFETs on when I don't want it can be dangerous. External circuit is always connected, and Pi operates automatically at distant place. I simply can't wait for it to settle and apply power by myself.

User avatar
rpdom
Posts: 15615
Joined: Sun May 06, 2012 5:17 am
Location: Chelmsford, Essex, UK

Re: GPIO initial state

Mon Jun 24, 2013 6:24 am

At startup the GPIO pins should be defined as inputs so the level will be undefined. Have you got external pull-down resistors on the gates of your MOSFETs? That should prevent them going high until your program defines the pins as outputs and sets them low.

User avatar
joan
Posts: 14481
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: GPIO initial state

Mon Jun 24, 2013 7:44 am

You can't depend upon the state of the gpios during Pi initialisation. Even if a solution appears to work now it might be broken in a subsequent firmware/kernel release.

PiGraham
Posts: 3671
Joined: Fri Jun 07, 2013 12:37 pm
Location: Waterlooville

Re: GPIO initial state

Mon Jun 24, 2013 8:34 am

joan wrote:You can't depend upon the state of the gpios during Pi initialisation. Even if a solution appears to work now it might be broken in a subsequent firmware/kernel release.
Is that really true? If so it has some serious implications for many Pi applications.A defined reset state is usually rather important for controllers of all sorts, for safety, EMC, product life etc. It wouldn't do for a motor to start running just because the Pi (or a microcontroller) was reset.

Designers should always assume that their Pi inputs may power up as outputs driving high or low, and never connect a Pi GPIO direct to another device's output pins?

Eben's "Raspberry Pi User Guide" says "by default , the Raspberry Pi's GPIO pins are switched off."

However, this topic discusses pins defaulting to output as the OS boots.

It would be good to know that at least one GPIO comes up in a guaranteed state so that safe power sequencing of permanently connected peripherals can be managed by application code.

User avatar
joan
Posts: 14481
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: GPIO initial state

Mon Jun 24, 2013 9:41 am

Just booted my soft float Pi. Gpio 0-31 modes are set as follows.

Code: Select all

 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
 4  4  4  4  0  1  1  0  0  0  0  0  0  0  4  4

16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
 1  0  0  0  0  0  0  0  0  0  0  1  0  0  0  0
0=input, 1=output, 4=ALT0

rownyr
Posts: 41
Joined: Wed Jul 11, 2012 1:25 am

Re: GPIO initial state

Mon Jun 24, 2013 10:20 am

rpdom wrote:At startup the GPIO pins should be defined as inputs so the level will be undefined. Have you got external pull-down resistors on the gates of your MOSFETs? That should prevent them going high until your program defines the pins as outputs and sets them low.
Of course, every gate has pull-down resistor. I have a LED connected on a high side of the N-MOSFET. Every time I power-on the Pi, the LED turns on for a few seconds. After boot, I can successfully control all MOSFETs using either my C program or gpio command.

The MOSFET with LED is connected to GPIO25.

User avatar
aTao
Posts: 1087
Joined: Wed Dec 12, 2012 10:41 am
Location: Howlin Eigg

Re: GPIO initial state

Mon Jun 24, 2013 10:07 pm

From the Broadcom peripheral data sheet then a cpu reset will set all GPIOs as inputs. The pull up/ pull down settings remain as was last set and even maintain their function during power down mode when the core is off (not to be confused with board power off)

It would however be a bad mistake to assume that the OS starting, or other resident software will not affect the pinsand, as such no external circuit should be powered during this time. Use a delay from RPi power on to enable power to the external circuit. If the RPi is used to control equipment that is always on, or cannot use a power on delay than an intermediate circuit should/must be used to buffer the control signal, ensuring that no rogue controls are sent. The buffer circuit could monitor the RPi power supply and act accordingly, or use a watchdog signal to determine control validity, or your control signal might be something other than on/off and therefore be unlikely to be generated by anything other than your code.

Note that the RPi as it stands, or even the Broadcom chip, was [edit]not![/edit] designed as an industrial PLC.

*Well that missed word wrecked my post, duhh!.
>)))'><'(((<

Return to “Advanced users”