Page 1 of 1

GPIO pins always on

Posted: Thu Feb 26, 2015 6:34 pm
by gruempy
Recently purchased the RP2 and was trying it out using the CAMJAM EduKits and in particular the 'pedestrian crossing' lab. Yesterday I finally got the breadboard configured and required GPIO pins programmed and it was working just fine (button, buzzer, 'traffic lights' and pedestrian lights.

This morning I was playing around trying to get VNC server working and also connecting to the RP from my laptop (I was going to take the lab into school to show the ICT group and wanted to make sure I had all connectivity I might need without needing to start scrabbling around looking for monitors. Anyway, throughout this exercise the lab was still connected with cables between the GPIO and the breadboard.

Anyway just happened to try out the pedestrian crossing programme this morning and discovered that various of the LEDS came on as soon as the power was applied to the RP2 and although parts of the programme worked (apparently correctly) the LEDs did not turn on and off as programmed,

I tried various simpler programmes to check the state of the pins and it looks like pins 23 and 24 are always on (and will not turn off) and pin 22 will come on but then not turn off again. I tried reloading Raspberian OS (in desperation) but problem persists.

I then swapped the cables onto my old RP B and the lab works perfectly so the problem seems to be the RP2. Do I have to assume that somehow I have damaged the RP2 and that there is no way to correct this issue - short of buying a new RP2 ?

Any help much appreciated


Re: GPIO pins always on

Posted: Thu Feb 26, 2015 7:09 pm
by joan
If you have wiringPi installed test the gpios with its pintest utility.

Alternatively use my gpio test script (requires pigpio).

During both tests nothing should be connected to the gpios.

Re: GPIO pins always on

Posted: Thu Feb 26, 2015 9:08 pm
by FTrevorGowen
Are you running the same versions of Raspbian on both Pis? (ie. what does uname -a report for each Pi). Raspbian for the P2B uses a different kernel version than might be running on your old B Pi** and the default settings/behaviour of the GPIO's may be different. Also the "pedestrian crossing lab" software, which I'm not familiar with, may need to be updated to work correctly on a P2B.
** unless it's recently been updated/upgraded.

Re: GPIO pins always on

Posted: Thu Feb 26, 2015 9:16 pm
by DougieLawson
FTrevorGowen wrote:Also the "pedestrian crossing lab" software, which I'm not familiar with, may need to be updated to work correctly on a P2B.
Take a look at the code: ... g-Word.pdf

Re: GPIO pins always on

Posted: Fri Feb 27, 2015 10:44 am
by gruempy
Hi thanks for the quick response. First just to be clear the pedestrian crossing (Python) lab was fully working on the RP-2 two days ago, the lab uses 7 GPIO pins as output controlling 6 LEDs and 1 buzzer plus one GPIO pin as input for a button.

The only changes that I made after it was working were to install and get tightvncserver running to support use of GUI in headless mode (already had SSH access sorted during lab development), then to modify the network config to use a static IP address on eth0, so I could connect from laptop to run in headless mode, and finally I was playing with getting the HDMI-VGA config working so that if I had problems with laptop access I could still use one of the school's VGA monitors to access the RP (this involved changing the /boot/config.txt file and connecting using the HDMI-VGA adapter purchased from PiHut - this was finally got working and I was able to use my VGA monitor with the RP-2).

As I said during this additional work the RP-2 GPIO pins were still connected to the breadboard but I was not running the lab. It was only by chance that I happened to try rerunning the lab, after this work and found that the pins 23 and 24 (BMC) seemed to be permanently on (i.e. the connected LEDs were lit). To make sure that nothing had changed on the breadboard, I simply swapped the cables from the GPIO on my RP-2 onto the GPIO on my older RP-B, copied the python code over and the lab worked perfectly.

On this basis the fault seemed to be the RP-2, I modified an earlier lab program, already on the RP-2, which simply switched LEDs on and off, already using same pins as the pedestrian lab, and observed that the turning off operation no longer turned off the two LEDS on pins 23, 24 (BMC). I modified the program to add the Python code to read the state of the outputs and it confirmed the PINs were remaining on, irrespective of the program control requesting them to be turned off. It also confirmed that PIN 22 was then coming on, after initially turning all LEDs on but then was no longer turning off and then remained permanently on.

Interestingly, I also have a PyGlow add-on card/module and that still runs perfectly on the RP-2 and also the RP-B - but of course that uses different GPIO pins to those that are affected. So again it seems as if the problem is specific to just these three pins and the rest of GPIO is working OK on the RP-2. I will try the pintest programme later but the evidence seems fairly conclusive that something in the GPIO subsystem (most likely hardware) has become damaged and in part this post was trying to understand what could have caused this (I am not really an electronics buff so am just following instructions in the lab docs but I would like to know what I might have done wrong so I can avoid in future). Also just looking if the consensus is that I need to get another RP-2 as the current one, whilst appearing to work normally as a Linux s/w platform has some serious question marks over its GPIO capability and therefore any future labs would also have the concern that errors might be due to this damage rather than faults in s/w or associated breadboard systems :-(

I'll post results of the pintest later when I get chance to install. Below is the Python programme I was using to simply test the pin out status

Code: Select all

import RPi.GPIO as GPIO
from time import sleep

    print "Pin 18 = ", GPIO.input(18)
    print "Pin 23 = ", GPIO.input(23)
    print "Pin 24 = ", GPIO.input(24)
    print "Pin 17 = ", GPIO.input(17)
    print "Pin 27 = ", GPIO.input(27)
    print "Pin 22 = ", GPIO.input(22)


    while True:

        print "Lights on"

        print "Pin 18 = ", GPIO.input(18)
        print "Pin 23 = ", GPIO.input(23)
        print "Pin 24 = ", GPIO.input(24)
        print "Pin 17 = ", GPIO.input(17)
        print "Pin 27 = ", GPIO.input(27)
        print "Pin 22 = ", GPIO.input(22)
        print "Lights off"

except KeyboardInterrupt:
    print "Ctrl-C pressed"

 #   print "Unknown exception"


Many thanks


Re: GPIO pins always on

Posted: Fri Feb 27, 2015 12:54 pm
by gruempy

Here are results of uname and also the gpiotest checks.

"uname -a" on RP-B
pi@jarpb ~ $ uname -a

Linux jarpb 3.18.7+ #755 PREEMPT Thu Feb 12 17:14:31 GMT 2015 armv6l GNU/Linux

"uname -a" on RP-2
pi@jarp2 ~ $ uname -a
Linux jarp2 3.18.7-v7+ #755 SMP PREEMPT Thu Feb 12 17:20:48 GMT 2015 armv7l GNU/Linux

so basically same versions of Linux just different hardware - correct ?

The gpiotest reported:
pi@jarp2 ~/PIGPIO $ ./
This program checks the Pi's (user) gpios.

The program reads and writes all the gpios. Make sure NOTHING
is connected to the gpios during this test.

The program uses the pigpio daemon which must be running.

To start the daemon use the command sudo pigpiod.

Press the ENTER key to continue or ctrl-C to abort...

Write 1 to gpio 17 failed.
Pull up on gpio 17 failed.
Write 1 to gpio 18 failed.
Pull up on gpio 18 failed.
Write 0 to gpio 23 failed.
Pull down on gpio 23 failed.
Write 0 to gpio 24 failed.
Pull down on gpio 24 failed.
Write 1 to gpio 27 failed.
Pull up on gpio 27 failed.
Skipped non-user gpios: 0 1 28 29 30 31
Tested user gpios: 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
Failed user gpios: 17 18 23 24 27

I also installed the piscope and captured that output - see attachment gpiotest_results.piscope but this just confirms the results seen in terminal window.

So looks like GPIO component is damaged, question is whether this is something I did or if there is/was a fault in the board ?

Again thanks


Re: GPIO pins always on

Posted: Fri Feb 27, 2015 1:24 pm
by joan
Oh well. It looks like you still have 21 working gpios so the board needn't be a write off. You have lost the use of the main SPI (chip selects 17/18).

You'd probably need to understand the internal structure of the gpios to work out the cause of that combination of failures.