User avatar
Un4Seen
Posts: 330
Joined: Wed Oct 31, 2012 8:43 am
Location: Cluj-Napoca, Romania
Contact: Website

GPIO state after boot

Mon Dec 03, 2012 12:09 am

Hi!

I have a piece of hardware connected to my Pi which basically lets the Pi control one LED with each of the programmable GPIO pins on the P1 connector. I keep these LEDs connected to the Pi all the time.This means that if a GPIO pin is on, the corresponding LED is on.
I have found that whenever the Pi boots up, pins (LEDs) 8,9 and 15 (according to the WiringPi numbering scheme: https://projects.drogon.net/raspberry-pi/wiringpi/pins/) are turned HIGH. At first it did not bother me much, but after a while it starts to be annoying that whenever I reboot the Pi, 3 out of the 17 LEDs are ON.
I have a bash script which opens all 17 pins in output mode and sets all pins to LOW. This works as a charm if I run it manually after the boot is complete and I log on. But I want to run this script automatically at startup. I've tried putting the script into /etc/init.d/myscript_gpio_off and adding the appropriate SXYmyscript_gpio_off file to /etc/rc2.d and to /etc/rc3.d. This is supposed to execute that script at startup, but for some reason it does not work. Those 3 LEDs are still ON after reboot. There are two possibilities: I'm doing something wrong e\when I'm adding those files to the /etc/init.d and etc/rcN.d directories, or maybe my script is executed as expected during boot but later something lights the LEDs back up.
The question is, how can I turn those LEDs off at startup, automatically?

Thanks!
Andras
http://iqjar.com

User avatar
Grumpy Mike
Posts: 917
Joined: Sat Sep 10, 2011 7:49 pm
Location: Manchester (England England)
Contact: Website

Re: GPIO state after boot

Mon Dec 03, 2012 12:34 pm

I think the only way is to fire off a complaint to the muppets that do the Linux distribution and ask then to stop screwing things up for people who actually use and understand hardware.

neilf
Posts: 72
Joined: Sun Nov 11, 2012 8:14 am

Re: GPIO state after boot

Mon Dec 03, 2012 2:16 pm

Just as a point of interest, the reason your three LEDs are on at start up is probably because five of the 17 available GPIO lines are pulled high by default (the rest are pulled low). The numbers are GPIO0/2, GPIO1/3, GPIO4, GPIO7 and GPIO8. I'm not familiar with Wiring Pi pin numbers but I expect you'll find your pins match up with some of those GPIOs.

The one exception might be your pin 15, which looks like it must be GPIO14. However, this pin isn't a GPIO at startup - it's TxD, the serial transmit line - which may well be pulled high for normal TX operation. The TxD line won't become GPIO14 (and therefore go low) until you run your script that enables all 17 lines as GPIOs.

Can't help with a startup script I'm afraid, as I only program Risc OS. Sorting your problem would be a doddle under Risc OS though ;-)

pjc123
Posts: 913
Joined: Thu Mar 29, 2012 3:37 pm
Contact: Website

Re: GPIO state after boot

Mon Dec 03, 2012 3:15 pm

neilf wrote:Just as a point of interest, the reason your three LEDs are on at start up is probably because five of the 17 available GPIO lines are pulled high by default (the rest are pulled low). The numbers are GPIO0/2, GPIO1/3, GPIO4, GPIO7 and GPIO8.
Thanks for that little tidbit of info. I also require a know state at boot and this explains why one of my GPIO pins was a "HIGH" at boot and the other one a "LOW" at boot. I have modified my circuitry accordingly.
neilf wrote: The one exception might be your pin 15, which looks like it must be GPIO14. However, this pin isn't a GPIO at startup - it's TxD, the serial transmit line - which may well be pulled high for normal TX operation. The TxD line won't become GPIO14 (and therefore go low) until you run your script that enables all 17 lines as GPIOs.
As I learned from the forums, I use an LED hooked up to GPIO14 and mounted on my chassis to notify me when the pi has completely shut down (The LED is lit at boot and is turned off at shutdown after the files systems have been unmounted.
My Raspberry Pi Project Page:
https://www.flaminghellmet.com/launch/

User avatar
Grumpy Mike
Posts: 917
Joined: Sat Sep 10, 2011 7:49 pm
Location: Manchester (England England)
Contact: Website

Re: GPIO state after boot

Mon Dec 03, 2012 4:10 pm

neilf wrote:Just as a point of interest, the reason your three LEDs are on at start up is probably because five of the 17 available GPIO lines are pulled high by default (the rest are pulled low). The numbers are GPIO0/2, GPIO1/3, GPIO4, GPIO7 and GPIO8.)
Sorry that is just plain wrong.
The only lines that have a pull up resistor fitted externally are the two I2C bus lines GPIO0/2, GPIO1/3. All the other lines start off as inputs with no pull up enabled. It is the code that is then run that messes about with them.

pjc123
Posts: 913
Joined: Thu Mar 29, 2012 3:37 pm
Contact: Website

Re: GPIO state after boot

Mon Dec 03, 2012 5:10 pm

Grumpy Mike wrote: All the other lines start off as inputs with no pull up enabled. It is the code that is then run that messes about with them.
What code are you talking about; the processor microcode, the OS? Because....

When I boot up, without setting up the GPIO pins through software that I write, I am pretty much seeing what neilf has stated (except for GPIO port 4). I just did measurements at bootup, and GPIO ports (not physical pins) 0, 1, 7, 8, 14 and 15 are all outputting 3.3 volts. All other GPIO ports measure as "LOW" or floating (not sure which one, but basically measuring as 0 volts). Also, these states are consistent with multiple bootups. By selecting the proper GPIO ports, I now have a consistent bootup state. Of course when I do run my code, I first insure that all the GPIO ports I am using are set as either an input or output, and set their state to "LOW" or "HIGH" where appropriate, before the meat of my program starts doing what I want.
My Raspberry Pi Project Page:
https://www.flaminghellmet.com/launch/

User avatar
Grumpy Mike
Posts: 917
Joined: Sat Sep 10, 2011 7:49 pm
Location: Manchester (England England)
Contact: Website

Re: GPIO state after boot

Mon Dec 03, 2012 8:43 pm

What code are you talking about;
I am talking about the processor itself. By default on power up all the GPIO pins are inputs with no pull up resistor.
Anything else is done by the code in the OS. That means if a pin is not powered up as an input some one has made the decision that that is the way it should be.
This give a real problem because the connector P1is not hot pluggable. That is, you should only connect to it with the power off. The fact that some muppet has decided that a totally unused pin should be an output can damage the processor with some designs of electronics you can plug into P1. With the muppets keeping on moving what is defined as an input or output on power up with different distro releases, they make it impossible to design anything safely.

As I said they either know nothing about hardware or hate people using hardware.

User avatar
jojopi
Posts: 3085
Joined: Tue Oct 11, 2011 8:38 pm

Re: GPIO state after boot

Mon Dec 03, 2012 9:58 pm

Grumpy Mike wrote:I am talking about the processor itself. By default on power up all the GPIO pins are inputs with no pull up resistor.
At power on, as neilf has said, five of the GPIOs are pulled up and the rest are pulled down. You could have tested that, simply by powering up a Pi with no SD card inserted. Or you could have consulted table 6-31 of the 2835 peripherals datasheet.
The fact that some muppet has decided that a totally unused pin should be an output can damage the processor with some designs of electronics you can plug into P1.
I am not seeing any pins configured as a hard output except where a driver has been loaded. I wonder whether you are, or if you are just spouting further unchecked facts.

User avatar
Grumpy Mike
Posts: 917
Joined: Sat Sep 10, 2011 7:49 pm
Location: Manchester (England England)
Contact: Website

Re: GPIO state after boot

Tue Dec 04, 2012 11:55 am

jojopi wrote:At power on, as neilf has said, five of the GPIOs are pulled up and the rest are pulled down. ..... Or you could have consulted table 6-31 of the 2835 peripherals datasheet.
Table 6-31 of the 2835 peripherals datasheet has the title "Alternative Function Assignments", that gives you the clue that it is not applicable to the state of the pins when they are GPIO. The clue is in the words. The reset states of the pull up / pull down registers is shown in Table 6-28 and Table 6-29 and 6-30 as being zero.
jojopi wrote:You could have tested that, simply by powering up a Pi with no SD card inserted.
Yes but that does not give you the default power up state. It gives you the state after the boot code ROM inside the chip has been run.
jojopi wrote:I am not seeing any pins configured as a hard output except where a driver has been loaded. I wonder whether you are, or if you are just spouting further unchecked facts.
Well with some versions of Raspbian I am seeing some pins set up as outputs. I have checked this.

User avatar
jojopi
Posts: 3085
Joined: Tue Oct 11, 2011 8:38 pm

Re: GPIO state after boot

Tue Dec 04, 2012 2:37 pm

Grumpy Mike wrote:Table 6-31 of the 2835 peripherals datasheet has the title "Alternative Function Assignments", that gives you the clue that it is not applicable to the state of the pins when they are GPIO. The clue is in the words. The reset states of the pull up / pull down registers is shown in Table 6-28 and Table 6-29 and 6-30 as being zero.
You are reading too much into the heading there. The whole of chapter 6 is GPIO and the pull states are shoehorned into the function table for convenience. The clue is the word also in "the Alternate function table also has the pull state which is applied after a power down".

The tables you cite show that the reset states of the pull registers are zero, as if pulls were disabled. But the text makes it clear that hardware pulls are actually retained over a reset, and for that reason you cannot expect to read the current pull state from the registers.

Again, if you doubt this you could easily test it. On a cold start (with or without SD card) GPIO7 is initially pulled high. After booting an OS to disable that pull-up, a hard reset (with or without SD card) will not reinstate it. I think this is also good evidence that the initial pull states are set in hardware, not by the boot ROM as you suggest. But of course that makes no difference because either way the behaviour cannot be changed or avoided.

Quite simply, anything attached to P1 must be safe with the default pulls given in 6-31, regardless of what OS you choose.
Well with some versions of Raspbian I am seeing some pins set up as outputs. I have checked this.
Are you still excluding pins that are being driven, such as UART TXD? If unused, or unlikely-to-be-used, pins are being configured as output then that absolutely needs to be fixed. That means tracing it to the firmware, kernel, or distro, and reporting as a bug. Vague talk of muppetry and hatred without even naming any pins in question is not helpful.

Incidentally, the three pins causing the problem for the OP were the I²C pair with hardware pull-ups, and TXD.

User avatar
Un4Seen
Posts: 330
Joined: Wed Oct 31, 2012 8:43 am
Location: Cluj-Napoca, Romania
Contact: Website

Re: GPIO state after boot

Tue Dec 04, 2012 8:39 pm

A few days have passed since I started this topic and I was wondering why nobody has posted an answer... well, because I forgot to watch the topic and so I have received no email notifications about it :) by the way, it would be great if topics created by a person would be watched automatically by that person.

Anyway, getting back to our own business, thank you guys for the replies :)
However, in the heat of the debate, nobody has really answered my question: how to run a script during start up which basically cancels whatever was done with the pins before, sets them all to output mode and sets them to LOW. I have the script and it works well.. just not during boot :(
Andras
http://iqjar.com

User avatar
[email protected]
Posts: 2020
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website

Re: GPIO state after boot

Tue Dec 04, 2012 8:41 pm

Un4Seen wrote:A few days have passed since I started this topic and I was wondering why nobody has posted an answer... well, because I forgot to watch the topic and so I have received no email notifications about it :) by the way, it would be great if topics created by a person would be watched automatically by that person.

Anyway, getting back to our own business, thank you guys for the replies :)
However, in the heat of the debate, nobody has really answered my question: how to run a script during start up which basically cancels whatever was done with the pins before, sets them all to output mode and sets them to LOW. I have the script and it works well.. just not during boot :(
If it's a list of wiringPi gpio commands, then stick in it /etc/rc.local (if you're using Raspbian)

-Gordon
--
Gordons projects: https://projects.drogon.net/

User avatar
Un4Seen
Posts: 330
Joined: Wed Oct 31, 2012 8:43 am
Location: Cluj-Napoca, Romania
Contact: Website

Re: GPIO state after boot

Tue Dec 04, 2012 8:42 pm

Un4Seen wrote:by the way, it would be great if topics created by a person would be watched automatically by that person.
Side note: I think I've found an option for this in my forum profile settings, so I guess it's possible, you just have to set it because it's not the default behavior.
Andras
http://iqjar.com

User avatar
Un4Seen
Posts: 330
Joined: Wed Oct 31, 2012 8:43 am
Location: Cluj-Napoca, Romania
Contact: Website

Re: GPIO state after boot

Tue Dec 04, 2012 8:44 pm

[email protected] wrote:
If it's a list of wiringPi gpio commands, then stick in it /etc/rc.local (if you're using Raspbian)

-Gordon
I've already tried it, doesn't work. I have the feeling that the pin states are modified after what runs from /etc/rc.local (although it clearly states that this runs at the end of the boot process). Yepp, it's Raspbian :)
Andras
http://iqjar.com

User avatar
[email protected]
Posts: 2020
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website

Re: GPIO state after boot

Tue Dec 04, 2012 8:48 pm

Un4Seen wrote:
[email protected] wrote:
If it's a list of wiringPi gpio commands, then stick in it /etc/rc.local (if you're using Raspbian)

-Gordon
I've already tried it, doesn't work. I have the feeling that the pin states are modified after what runs from /etc/rc.local (although it clearly states that this runs at the end of the boot process). Yepp, it's Raspbian :)
there is no $PATH set, so make sure you use

/usr/local/bin/gpio ...

in the script.

(I just checked on a Pi with one of my ladder boards connected - works fine)

-Gordon
--
Gordons projects: https://projects.drogon.net/

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

Re: GPIO state after boot

Tue Dec 04, 2012 8:49 pm

You could add a crontab reboot entry.

sudo crontab -e

See

man 5 crontab

for details.

If you go that route add a sleep 5 seconds or so at the start of the script to make sure other system processes have initialised.

User avatar
Un4Seen
Posts: 330
Joined: Wed Oct 31, 2012 8:43 am
Location: Cluj-Napoca, Romania
Contact: Website

Re: GPIO state after boot

Tue Dec 04, 2012 9:02 pm

[email protected] wrote: there is no $PATH set, so make sure you use

/usr/local/bin/gpio ...

in the script.

(I just checked on a Pi with one of my ladder boards connected - works fine)

-Gordon
That could be it! I'll give it a try.
Andras
http://iqjar.com

User avatar
Un4Seen
Posts: 330
Joined: Wed Oct 31, 2012 8:43 am
Location: Cluj-Napoca, Romania
Contact: Website

Re: GPIO state after boot

Tue Dec 04, 2012 9:02 pm

joan wrote:You could add a crontab reboot entry.

sudo crontab -e

See

man 5 crontab

for details.

If you go that route add a sleep 5 seconds or so at the start of the script to make sure other system processes have initialised.
Yes, I was thinking about the sleep, I'll probably add it.
Andras
http://iqjar.com

User avatar
Un4Seen
Posts: 330
Joined: Wed Oct 31, 2012 8:43 am
Location: Cluj-Napoca, Romania
Contact: Website

Re: GPIO state after boot

Tue Dec 04, 2012 9:29 pm

Wow! It works! the problem was what Gordon mentioned: I needed to call the gpio utility with absolute path because the PATH was not ready. It works even without delay. This is actually more useful than I thought. It's not just that the LEDs are off at start up, but also I know when the Pi has finished booting (when the LEDs go off) :)

For anybody interested, this is how my script looks like (I've put it into /etc/init.d/gpio_all_off.bash):

Code: Select all

#! /bin/bash

#Initializes all gpio pins to output mode and sets them all LOW

#sleep 1
for i in `seq 0 16`; do /usr/local/bin/gpio mode $i out; done
for i in `seq 0 16`; do /usr/local/bin/gpio write $i 0; done
Note that it requires the WiringPi gpio command line utility to be installed (see here: https://projects.drogon.net/raspberry-p ... d-install/).

My /etc/rc.local looks like this now:

Code: Select all

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.

/etc/init.d/gpio_all_off.bash

exit 0
Thank you for the help, guys!
Andras
http://iqjar.com

spliffmo
Posts: 1
Joined: Fri Feb 08, 2013 9:04 pm

Re: GPIO state after boot

Fri Feb 08, 2013 9:08 pm

Un4Seen,

I have a similar problem to yours and I was hoping you could shed some light on the issue. I am controlling a bunch of relays with the rPi however they all use a common bus. During startup some of the GPIOs go high and connect a bunch of relays to the common bus which in turn freezes my pi. I need to turn them off during start up so this doesn't happen.

User avatar
Un4Seen
Posts: 330
Joined: Wed Oct 31, 2012 8:43 am
Location: Cluj-Napoca, Romania
Contact: Website

Re: GPIO state after boot

Fri Feb 08, 2013 11:18 pm

Hi there!

What I did is this:
1. Into /etc/rc.local I have enetered this line:

Code: Select all

/etc/init.d/gpio_all_off.bash
2. I have created a shell script under /etc/init.d called gpio_all_off.bash, into which I have entered the following:

Code: Select all

#! /bin/bash

#Initializes all gpio pins to output mode and sets them all LOW

#sleep 1
for i in `seq 0 16`; do /usr/local/bin/gpio mode $i out; done
for i in `seq 0 16`; do /usr/local/bin/gpio write $i 0; done
Note that for this to work you will need to install Gordon's gpio utility. Follow his guide: https://projects.drogon.net/raspberry-p ... d-install/
Alternatively, you can also create some other script to turn off your gpio pins, Python perhaps, or something else.

The big problem is, unfortunately, that the GPIO pins mentioned above (8,9 and 15 I think according to the WiringPi numbering) do not turn off immediately. Quite a few seconds will pass before the /etc/rc.local script is executed. Until that moment these pins will be high. Perhaps you can avoid connecting to these pins?
Andras
http://iqjar.com

User avatar
[email protected]
Posts: 2020
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website

Re: GPIO state after boot

Sat Feb 09, 2013 11:05 am

Un4Seen wrote:Hi there!

What I did is this:
1. Into /etc/rc.local I have enetered this line:

Code: Select all

/etc/init.d/gpio_all_off.bash
2. I have created a shell script under /etc/init.d called gpio_all_off.bash, into which I have entered the following:

Code: Select all

#! /bin/bash

#Initializes all gpio pins to output mode and sets them all LOW

#sleep 1
for i in `seq 0 16`; do /usr/local/bin/gpio mode $i out; done
for i in `seq 0 16`; do /usr/local/bin/gpio write $i 0; done
Note that for this to work you will need to install Gordon's gpio utility. Follow his guide: https://projects.drogon.net/raspberry-p ... d-install/
Alternatively, you can also create some other script to turn off your gpio pins, Python perhaps, or something else.

The big problem is, unfortunately, that the GPIO pins mentioned above (8,9 and 15 I think according to the WiringPi numbering) do not turn off immediately. Quite a few seconds will pass before the /etc/rc.local script is executed. Until that moment these pins will be high. Perhaps you can avoid connecting to these pins?
I would be very carefull with doing this.

Off can mean many things to many people :)

Your script is setting the pins to output mode then setting them low. If they are connected to anything that can source current, you've just shorted that to ground.

But if it's something completely under your control, then it might be OK.

If you want it to happen quicker during the boot sequence, then you might want to put it into the file /etc/init.d/udev - at the end of the 'start' sequence, however giving it it's own /etc/init.d file to be executed after udev is arguably the more correct thing to do!

Finally - seq 0 16 includes the 2 UART pins - If you're using the UART, then seq 0 14 might be better.


-Gordon
--
Gordons projects: https://projects.drogon.net/

User avatar
Un4Seen
Posts: 330
Joined: Wed Oct 31, 2012 8:43 am
Location: Cluj-Napoca, Romania
Contact: Website

Re: GPIO state after boot

Sat Feb 09, 2013 12:23 pm

Gordon is right. For me the approach described above did the job, as I only have 17 LEDs connected to the GPIO pins. You might not want to mess with all the pins and you might need to be careful about about shorting things to ground. I fear that you won't be able to avoid having the pins HIGH for at least a brief moment after startup and you'll also have some pins HIGH after a shutdown.
Andras
http://iqjar.com

wiegleyj
Posts: 1
Joined: Tue Dec 09, 2014 6:34 am

Re: GPIO state after boot

Tue Dec 09, 2014 6:58 am

Grumpy Mike is EXACTLY right. From my reading of this thread nobody took the time to really understand
what he is saying and I think it does go to show that the raspberry pi is not being programmed and used
by hardware engineers. I'll try to explain the problem in more details.

In any embedded system with GPIO pins that can be configured as a multitude of functions it is
imperative that they start in a high impedance state (such as an input pin). Only the intended purpose's
firmware/software should change their states (the operating system is NOT the intended purpose
software). This is not just a cooperatively good thing to do it is a safety necessity in embedded
control electronics.

Let's say you are building something where your GPIO pin will eventually be used control a high voltage
source. Let's say a cardiac defibrillator. As the machine is booting up you certainly NEVER want the
OS to turn a pin on as a high output. You will probably kill the poor soul who just turned it on and isn't
prepared with the paddles in place and hasn't purposely activated the button. You don't want this to
happen for even a second. Notice that I'm not just talking about the bcm2835's powerup sequence
which Mike points out correctly has EVERYTHING turn off; I am talking about the operating system which
as he pointed out here as done the very wrong thing of assuming you should have some output.
The operating system knows nothing of the purpose for which this device is going to be used and so
it should instead enforce the safest possible start conditions (everything off). (This is exactly why the
bcm2835 and all other microcontrollers startup with their GPIO pins in the input state with no pull-ups)

The proper way is to ALWAYS have all general purpose pins start in a high impedance state and stay
that way until the product's final function is active. This way the device will not activate anything
external to itself accidentally and it will suffer being connected to anything even if that other thing is
not so safely/wisely programmed.

The proper sequence is that the OS should complete booting and NEVER have turned any GPIO
pin to an output. The application software should first set the output value of the desired GPIO pin (which
won't affect the voltage on the pin because it is still in the input mode). Once that pin's value
is pre-programmed in the cpu output register then the pin's direction can be switched from input mode to
output by the application.

This way. if you are the defibrillator's application software you first set the pin's value to LOW (but still
in input mode) and when you then switch the pin to output you don't trigger the high voltage relays or
external device. (If your external equipment is active with a low signal then you would simply set the
pin's value to HIGH before activating it as output.

Sorry, gonna go with Mike on this. The raspberry pi OS developers certainly do not dabble
in serious external electrical design. Right now the raspberry pi OS makes a serious mistake in
assuming that you want these pins in output mode; even worse HIGH output pins ZAAAAAAAP!.
The only correct configuration for a bare-bones general application operating system is that it
start with all GPIO pins in the input direction with pull-ups off.

Basically everything about the operating system should safely start up disconnected/isolated
from everything in the world and only the application software should change this because it is
the only thing that is programmed with an actually knowledge and intention of what it will be
controlling and interfacing with.

User avatar
jojopi
Posts: 3085
Joined: Tue Oct 11, 2011 8:38 pm

Re: GPIO state after boot

Tue Dec 09, 2014 8:17 am

wiegleyj wrote:(This is exactly why the bcm2835 and all other microcontrollers startup with their GPIO pins in the input state with no pull-ups)
As discussed previously, the 2835 actually powers up with the pull states given in Table 6-31 of the datasheet. It would be pointless to disable these later or pretend they did not exist.

If you are building a Pi-connected electrocution machine, you should look into the device tree based pin configuration that is available in newer firmware: http://www.raspberrypi.org/documentatio ... uration.md

Other than that I agree that pins should be left as inputs until they are used. If you are aware of specific images that drive pins (other than UART TXD) without positive action by the end user, please report those as a bug. Vague "OS developers certainly do not dabble in serious external electrical design" is still not helping.

Return to “Interfacing (DSI, CSI, I2C, etc.)”