GPIO Pin States a Boot time - Change in 3.6.11+

[gordon@drogon.net]

Just FYI - if you're relying on the pins to be set to a particular state at boot time, then DON'T.

Their behaviour has changed from kernels 3.2 to 3.6 - and I'm presuming this is due to the I2C changes and camera module..

It's mostly important on a Rev 1 board - the 2 exposed I2C pins (BCM_GPIO 0 and 1) are now set to OUTPUT and their outputs driven LOW.

This probably won't have any effect on a locally connected I2C bus but if you've connected anything else to those pins and are relying on them being at 3.3v at boot time, then they will be - for about 10 seconds until something in the kernel reconfigures them to output mode and hold them low.

gpio readall outputs:

Rev 1 pin state at boot time:

Code: Select all

+----------+-Rev1-+------+--------+------+-------+
| wiringPi | GPIO | Phys | Name   | Mode | Value |
+----------+------+------+--------+------+-------+
|      0   |  17  |  11  | GPIO 0 | IN   | Low   |
|      1   |  18  |  12  | GPIO 1 | IN   | Low   |
|      2   |  21  |  13  | GPIO 2 | IN   | Low   |
|      3   |  22  |  15  | GPIO 3 | IN   | Low   |
|      4   |  23  |  16  | GPIO 4 | IN   | Low   |
|      5   |  24  |  18  | GPIO 5 | IN   | Low   |
|      6   |  25  |  22  | GPIO 6 | IN   | Low   |
|      7   |   4  |   7  | GPIO 7 | IN   | Low   |
|      8   |   0  |   3  | SDA    | OUT  | Low   |  <--- Set to output
|      9   |   1  |   5  | SCL    | OUT  | Low   |  <--- Set to output
|     10   |   8  |  24  | CE0    | IN   | Low   |
|     11   |   7  |  26  | CE1    | IN   | High  |
|     12   |  10  |  19  | MOSI   | IN   | Low   |
|     13   |   9  |  21  | MISO   | IN   | Low   |
|     14   |  11  |  23  | SCLK   | IN   | Low   |
|     15   |  14  |   8  | TxD    | ALT0 | High  |
|     16   |  15  |  10  | RxD    | ALT0 | High  |
+----------+------+------+--------+------+-------+

Rev 2 pin state at boot time:

Code: Select all

+----------+-Rev2-+------+--------+------+-------+
| wiringPi | GPIO | Phys | Name   | Mode | Value |
+----------+------+------+--------+------+-------+
|      0   |  17  |  11  | GPIO 0 | IN   | Low   |
|      1   |  18  |  12  | GPIO 1 | IN   | Low   |
|      2   |  27  |  13  | GPIO 2 | IN   | Low   |
|      3   |  22  |  15  | GPIO 3 | IN   | Low   |
|      4   |  23  |  16  | GPIO 4 | IN   | Low   |
|      5   |  24  |  18  | GPIO 5 | IN   | Low   |
|      6   |  25  |  22  | GPIO 6 | IN   | Low   |
|      7   |   4  |   7  | GPIO 7 | IN   | Low   |
|      8   |   2  |   3  | SDA    | IN   | High  |
|      9   |   3  |   5  | SCL    | IN   | High  |
|     10   |   8  |  24  | CE0    | IN   | Low   |
|     11   |   7  |  26  | CE1    | IN   | Low   |
|     12   |  10  |  19  | MOSI   | IN   | Low   |
|     13   |   9  |  21  | MISO   | IN   | Low   |
|     14   |  11  |  23  | SCLK   | IN   | Low   |
|     15   |  14  |   8  | TxD    | ALT0 | High  |
|     16   |  15  |  10  | RxD    | ALT0 | High  |
|     17   |  28  |   3  | GPIO 8 | IN   | Low   |
|     18   |  29  |   4  | GPIO 9 | IN   | Low   |
|     19   |  30  |   5  | GPIO10 | IN   | Low   |
|     20   |  31  |   6  | GPIO11 | IN   | Low   |
+----------+------+------+--------+------+-------+

Note - this is without the I2C modules loaded into the kernel. If they do get loaded at boot time, then the outputs go through the sequence: Input (pull high) -> Output (Driven LOW) -> ALT0 (Pull high)

-Gordon

[lasseliten]

Thank you for this information.
On my first Raspberry Pi B version 1.0 with squeeze I used pins 11 and 13 (and 15, 16) successfully.
I bought a new one, B version 2.0, last week using wheezy. I noticed yesterday that using physical pin 8 and 10 they went high on boot which the physical pins 11 and 13 did not do.
I assumed that it has something to do with 2.0 or wheezy but with your information I know that I can expect the same with older board and O/S and I will stay away from 8, 10 and some other pins.

[gordon@drogon.net]

Thank you for this information.
On my first Raspberry Pi B version 1.0 with squeeze I used pins 11 and 13 (and 15, 16) successfully.
I bought a new one, B version 2.0, last week using wheezy. I noticed yesterday that using physical pin 8 and 10 they went high on boot which the physical pins 11 and 13 did not do.
I assumed that it has something to do with 2.0 or wheezy but with your information I know that I can expect the same with older board and O/S and I will stay away from 8, 10 and some other pins.

I've since discovered some other changes that I can't adequately explain. I have several Pi's and 2 of them bring some pins up in a different state to all the others - the issue sticks with the Pi - ie. I can swap SD cards and it makes no difference.

The only thing to learn here is that you MUST NOT rely on any pin being set to any state at boot time. If you are controlling critical machniery (and garage doors sem to be popular), then you must design an additional interlock circuit to cope with the Pi being rebooted or power cycled.

-Gordon

[multimedia]

I think its important to have no pin state changes (all low would be good) at boot and then allow only after boot has finished I wish to know how I can set this within the linux os (wheezy

[jeffhaddow]

Hello

I don't know if this is a related problem but I have a setup that woks fine (although with occasional crashes) with an Old NOOBS card but I recently tried another SD card with a new version of the NOOBS software and was unable to get my setup to work.

My setup is for continuous reading of temperature with outside and room measurement displays. It is a bit tempramental and I regularly have to scrub the Noobs card back to reinstalling raspian and perform some setting up procedures to get it back to life. I have two temperature sensors connected to gpio4 (pin 7) and drawing power from the 3.3v on pin1 there is also two 7-segment 4 digit led displays from Adafruit on the i2c interface pins. It measues the temperature outside and inside my living room and continuously displays them. The setup is serviced by a Python program that additionally displays a graph of the last 4 days of recorded reading and every hour stores the (every 6 mins) readings on a usb stick.

With the updated software I was either able to read the temperature but not display it on the led displays OR unable to read the temperature but the led displays show 0.00 . Initially when I reboot the system the temperature sensor works. If I open a terminal and enter "sudo modprobe w1_therm" and "sudo modprobe w1_gpio" followed by "sudo i2cdetect -y 0" the result is a display saying that all the available addresses are connected.

I'm at a loss how to fix this. I was wanting to try the new NOOBS software in the hope that the problems with the crashes would be solved. However I have had to return to the old SD card.

All the best
Jeff Haddow

[LinuxCircle]

I used Raspberry Pi 2 GPIO 4 as one of the pins connected to control DRV8833 motor driver.

For some reason GPIO 4 is stubornly stayed on HIGH on boot and moved the motor unwantedly, until a script forced it to be LOW. The other 3 pins connected to the driver seem to be starting low on boot. Is there anything special with this pin 4?

[DougieLawson]

I use Raspberry Pi 2 GPIO 4 as one of the pins connected to control DRV8833 motor driver.

For some reason GPIO 4 is stubonrly staying on HIGH on boot and move the motor, until a script force it to low. All other pins seem to be staring low on boot. Is there anything special with this pin?

By default GPIO4 is used for the 1-wire interface.

[jojopi]

By default GPIO4 is used for the 1-wire interface.

No, by default GPIO4 is left as an input, like most others. The Pi has no hardware support for 1-wire interface, so you should not see any implementation of that protocol unless you have configured it in software.

The reason that GPIO4 is weakly high at boot is that it is one of the few GPIOs whose power-on state is pulled high, rather than low. See Table 6-31 in the Peripheral specification, page 102. If that is a problem for external hardware you can use a ~10kΩ pull down resistor.

[d0n13]

Hi all

This might solve the issue for some people as adding pull down/up resistors is a pain but may be necessary if the pin is controlling something that depends on a trigger. However, if you are using relays like I am and need to avoid this issue here is a solution. I'm using a SunFoundry relay board like this one, http://www.amazon.com/SunFounder-Channe ... B00E0NSORY

Note that this board switches on when it gets a low instead of a high. i.e.: the logic is reversed. But that's ok once you take it into account.

In your /etc/rc.local add the following

Code: Select all

# setup the gpio pins for gate control
/home/pi/opener/setupgpio.sh

Then in setupgpio.sh add the following:

Code: Select all

#!/bin/sh

/usr/local/bin/gpio write 0 1
/usr/local/bin/gpio write 1 1
/usr/local/bin/gpio write 2 1

/usr/local/bin/gpio mode 0 output
/usr/local/bin/gpio mode 1 output
/usr/local/bin/gpio mode 2 output

echo "GPIO ports setup"

This set the pings HIGH (off on relay board) before setting them as outputs so they won't cause the relays to toggle when set as outputs.

Hope this helps somebody.
Donie

[HRodrigues]

Hi all

This might solve the issue for some people as adding pull down/up resistors is a pain but may be necessary if the pin is controlling something that depends on a trigger. However, if you are using relays like I am and need to avoid this issue here is a solution. I'm using a SunFoundry relay board like this one, http://www.amazon.com/SunFounder-Channe ... B00E0NSORY

Note that this board switches on when it gets a low instead of a high. i.e.: the logic is reversed. But that's ok once you take it into account.

In your /etc/rc.local add the following

Code: Select all

# setup the gpio pins for gate control
/home/pi/opener/setupgpio.sh

Then in setupgpio.sh add the following:

Code: Select all

#!/bin/sh

/usr/local/bin/gpio write 0 1
/usr/local/bin/gpio write 1 1
/usr/local/bin/gpio write 2 1

/usr/local/bin/gpio mode 0 output
/usr/local/bin/gpio mode 1 output
/usr/local/bin/gpio mode 2 output

echo "GPIO ports setup"

This set the pings HIGH (off on relay board) before setting them as outputs so they won't cause the relays to toggle when set as outputs.

Hope this helps somebody.
Donie

I'm facing the same problem and will try this solution. I have a sainsmart 8 channel relay board that activate on ( Low Output ) but when reboots or i do GPIO.cleanup() it changes the pin to input state..

[d0n13]

Ok, slight bug in the code snippet for setupgpio.sh above. Swap the sections that setup the ports as outputs before writing to them. But I don't think it really solves the problem as you'll still get a short instance where the output toggles.

The real problem is with the gpio software that sets the mode. Ideally, it should allow you to set the state of the output when it's configured. Not afterwards as there will be a slight delay in the two commands being executed.

I'll ask Gordon over at WiringPI to see if he can help... (http://wiringpi.com)

Code: Select all

#!/bin/sh

/usr/local/bin/gpio mode 0 output
/usr/local/bin/gpio mode 1 output
/usr/local/bin/gpio mode 2 output

/usr/local/bin/gpio write 0 1
/usr/local/bin/gpio write 1 1
/usr/local/bin/gpio write 2 1

echo "GPIO ports setup"

[gordon@drogon.net]

Ok, slight bug in the code snippet for setupgpio.sh above. Swap the sections that setup the ports as outputs before writing to them. But I don't think it really solves the problem as you'll still get a short instance where the output toggles.

The real problem is with the gpio software that sets the mode. Ideally, it should allow you to set the state of the output when it's configured. Not afterwards as there will be a slight delay in the two commands being executed.

I'll ask Gordon over at WiringPI to see if he can help... (http://wiringpi.com)

Code: Select all

#!/bin/sh

/usr/local/bin/gpio mode 0 output
/usr/local/bin/gpio mode 1 output
/usr/local/bin/gpio mode 2 output

/usr/local/bin/gpio write 0 1
/usr/local/bin/gpio write 1 1
/usr/local/bin/gpio write 2 1

echo "GPIO ports setup"

This works. You can set the output level before switching a pin from input (the default) to output.

However if you're using a samesmart relay do note that it is designed to work with a 5v system (e.g. Arduino) and not a Pi. the ones that switch on a low output (which is no bad thing) are putting 5 into the Pi's GPIO pin. (through a resistos and LED, however it's still not ideal)

Buy kit designed for the Pi, not kit where some shady ebay/amazon seller ust puts the words "Raspberry Pi" in the description to trick you. I've had 100's of emails from people who've done this. In extreme cases (there are many, many bad clones )-: the only way to make it work is to set the pin to input mode to turn the relay off, then output mode, low to enable the relay.

-Gordon

[photomankc]

This is good reason to use a buffer with an OE (output enable) line in real-world interfacing. I ran into this in another project on a different SBC and narrowly missed a direct high-low contention issue that would have likely done some damage. I really like using 74VHC244's in this role. They can take inputs higher than VCC and bring them to 3.3V on the Raspberry. The OE then blocks incoming signals until your app is running and enables the inputs and presumably has the I/O properly configured. It also can be placed onto outputs to make sure that random startup signals are not passed on to the rest of the circuit until the OE line is activated. Of course that means you need to be able to count on at least two GPIO's not to startup as LOW / OUTPUT so not completely safe either.

In the world of MCU's the rule is generally all I/O starts as an input so that an MCU not running a program can't create contention. Different story when it is an SBC running an OS that may be doing things with pins outside of any user application.

RaspberryPi is a cake-walk to interface to in general compared to something like the Beagle Bone Black where there are so many overlapping uses of the GPIO pins so it's a small gripe.

[hurz]

To chime in on this discussion:

I'm currently working on a little project also using one of these relay boards that activate on "low" to trigger the power supply to the amplifier fed by the raspberry pi + DAC (and a little delayed the actual speaker output). So the Pi should work as the music source and also the logic control point (later also as an input for a rotary volume encoder and power button).

But the above does not work for me as whenever I set a GPIO as an output it is always set low first, regardless of what I set it prior to the export command. However I believe this may be due to the implementation in WiringPi (as it works by other means, see below) but haven't looked further into this yet.

A way of avoiding this though is to use the regular echo commands to set the gpio states:
If you echo "high" to a previously exported GPIO's direction file, instead of first echo-ing "out" and then "1" into the value file, this will set the GPIO as a high output directly without initializing the low state first.
However, as the direction file is owned by root I could not do this in a user script without running a root subshell.

Now the below code works for me and the output doesn't trigger momentarily due to timing issues with the commands.
The drawback is that I need to input the sudo password, so I'm not happy with the result yet but it may be of help to somebody in the meantime and I'm open to suggestions. E.g. can I create the direction file as user-owned or some other workaround?
Or do I bypass this problem in general if I run this script at startup (as I assume the startup processes wouldn't have an issue with these access rights)?

I'm of course also willing to further investigate the issue with WiringPi not accepting the value of the GPIO pin before setting it as an output by using the code first posted by Donie above as Gordon mentioned this should in fact work?
And please forgive me if I'm missing something obvious, it's been a few years since I've actively used a Linux OS so I'm in the process of reacquainting myself...

Code: Select all

#!/bin/sh

echo 2 > /sys/class/gpio/export
sudo sh -c 'echo high > /sys/class/gpio/gpio2/direction'
echo 3 > /sys/class/gpio/export
sudo sh -c 'echo high > /sys/class/gpio/gpio3/direction'

echo "GPIO ports setup"

[jojopi]

However, as the direction file is owned by root I could not do this in a user script without running a root subshell.

The permissions on the direction files should be the same as on the export file. They are all owned by root, but also writeable by members of the "gpio" group.

However, I expect the problem you are seeing is because your script writes to the files immediately after exporting them. There will be a window between the kernel creating the files and udev setting their final permissions.

You could add a short sleep between the exports and the writes, but that is rather inelegant. I believe the following is reliable:

Code: Select all

echo 2 > /sys/class/gpio/export
echo 3 > /sys/class/gpio/export
udevadm settle
echo high > /sys/class/gpio/gpio2/direction
echo high > /sys/class/gpio/gpio3/direction

[gordon@drogon.net]

To chime in on this discussion:

I'm currently working on a little project also using one of these relay boards that activate on "low" to trigger the power supply to the amplifier fed by the raspberry pi + DAC (and a little delayed the actual speaker output). So the Pi should work as the music source and also the logic control point (later also as an input for a rotary volume encoder and power button).

But the above does not work for me as whenever I set a GPIO as an output it is always set low first, regardless of what I set it prior to the export command. However I believe this may be due to the implementation in WiringPi (as it works by other means, see below) but haven't looked further into this yet.

wiringPi doesn't force anything. never has, never will. that's up to you. If you want a pin to be high when you change it from the default input to output, then set it high. it' as simple as that.

Code: Select all

  digitalWrite (pin ,1) ;
  pinMode (pin, OUTPUT) ;

or from the keyboard/shell scripts:

Code: Select all

  gpio write $pin 1
  gpio mode $pin out

simples.

However I can't work out why you're using the sysfs interface when you can use the gpio command to do this for you.

-Gordon

[hurz]

Ok, let me try to explain again.

If I use WiringPi commands, like

Code: Select all

gpio -g write 2 1
gpio export 2 out

This will set GPIO 2 as output with state LOW (0). The initial 1 is apparently overwritten.
I'd have to do a subsequent

Code: Select all

gpio -g write 2 1

it will go HIGH but the attached relay will shortly trigger.

Exactly the same behaviour as doing (bash directly, no WiringPi):

Code: Select all

echo "2" > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio2/direction
echo "1" > /sys/class/gpio/gpio2/value

However, doing the following will set the GPIO to output and directly HIGH (no short initialization as LOW):

Code: Select all

echo "2" > /sys/class/gpio/export
echo "high" > /sys/class/gpio/gpio2/direction

Now your posted code only works for me if i had exported the pin first via echo (not via gpio export), otherwise the mode command would fail. But then it also results in the desired behaviour (initializing output as high), basically a mix of bash and WiringPi commands.

Code: Select all

echo "2" > /sys/class/gpio/export
gpio -g write 2 1
gpio -g mode 2 out

That also solves my problem with the access I mentioned above, so I will use that code going forward.
I was just wondering about the differences between bash and WiringPi.
It seems the command "gpio export #pin out" always sets the output to LOW, regardless of a previous "gpio write" command. I can reproduce that easily and it also happens if the pin has been previously exported by bash, e.g.:

Code: Select all

echo "2" > /sys/class/gpio/export
gpio -g write 2 1
gpio -g export 2 out

The export command will reset the output to low. The mode command doesn't.
Just wondered why that is?

That brings me to your question why I use sysfs commands instead of the gpio one:
How would I export a pin as a high output without a bash command involved (e.g. WiringPi only) AND without at least momentarily toggling the low state. As any use of "gpio export" will trigger the low (or possibly default?) state of the pin first.

Regards,
Raul

EDIT: Just to rule out any influence of SW versions, I'm using Volumio (so basically Raspbian) kernel 4.4.9+ and wiringpi 2.24

[hurz]

However, I expect the problem you are seeing is because your script writes to the files immediately after exporting them. There will be a window between the kernel creating the files and udev setting their final permissions.
You could add a short sleep between the exports and the writes, but that is rather inelegant. I believe the following is reliable ...

Thank you for this, that code works perfectly!
This seems to be the most elegant solution to solve the problem.
I'm of course still interested in why exporting the pin via WiringPi apparently does act differently or if there is a way to achieve the same with only using the gpio command?