Page 1 of 1

GPIO pin will not hold its output value

Posted: Fri Jun 19, 2015 8:11 pm
by tercel
I've been a Raspberry Pi user for a while now, but this is my first experience with the GPIO. I am trying to use it in a very simple application to command a relay board (simple 1:1 GPIO-pin-to-relay relationship).

My problem is that GPIO pin 27 (BCM mapping) will not hold its commanded output value.

Using the Python RPi.GPIO library, I set the pin to output mode, and then command it to GPIO.HIGH. Probing the pin directly (no relay board attached), I see it transition to high output, hold for about 20-30 seconds, and then transition back to low. This also happens when commanding the pin via the command line using:

Code: Select all

cd /sys/class/gpio
echo 27 > export
cd gpio27
echo out > direction
echo 1 > value
I have two RPi's, and even tried swapping my SD card into the other board (in the suspicion this was a hardware issue), and have exactly the same behaviour. I've searched this forum and google and found nothing similar to this problem. Any help or suggestions anyone can offer on here would be greatly appreciated. This is for an irrigation controller project, and every day I go without a solution to this, is one more more day my girlfriend has to spend 1.5 hours manually watering our vegetables... :)

Thanks all!

Re: GPIO pin will not hold its output value

Posted: Fri Jun 19, 2015 9:28 pm
by ghp
Hello, how do you probe the output ?
Are you sure that no other programs are running working with GPIO in the background ?
And could you give more details on the relais board ? photo, schema, description.

And last not least: The P1-13-pin has changed assignment between R1 and R2 of the Pi. If you own a very early device, there is no GPIO27 on the pin P1-13, but GPIO21.


Re: GPIO pin will not hold its output value

Posted: Sat Jun 20, 2015 11:49 am
by panik
A pin will return to an input as soon as it is unexported: viewtopic.php?f=44&t=99113

It should stay high if you don't unexport the pin or close/end the program. RPi.GPIO should automatically clean up after itself when the program closes, but I'm not 100% sure it does that.

What you wrote in the command line should work though (it should stay high). Does this happen to other pins?

Re: GPIO pin will not hold its output value

Posted: Sun Jun 21, 2015 6:39 pm
by tercel
Hi guys, thanks for your replies.

OK, I'm back at my Pi now.

First, to answer Gerhard's questions:

1) I probe the output with either a logic probe or my Bitscope (which has a bunch of logic inputs I can display the state of onscreen)
2) I have no other user level applications running at all, so are there any other system services I should be suspecting of affecting the GPIO?
3) this is the relay board: ... 19912.html
It is a simple 1:1 pin mapping to relay, active LOW.
4) My RPi is Model B, Rev 2 (2011.12) with the 26 pin GPIO. I'm pretty confident GPIO 27 is on pin 13, and I can see its levels change when I set it via RPi.GPIO and/or /sys/class/gpio. I tried the same with GPIO 21 just to be sure, and saw nothing happen on pin 13.

To panik's reply:

My test Python program (and indeed, using /sys/class/gpio) is not unexporting the pin. The program runs a simple while loop waiting for input, and only does a GPIO.cleanup() on exit.
Here's the program:

Code: Select all

valid_chan_list = [3, 4, 7, 8, 9, 10, 11, 14, 15, 17, 18, 22, 23, 24, 25, 27]
# set all to default output HIGH, because the relay board is reverse logic
GPIO.setup(valid_chan_list, GPIO.OUT, initial=GPIO.HIGH)
    chan = int(raw_input('input channel #:') )
    # if the user inputs 0, give a listing of current output levels
    if chan == 0:
      print('current channel output levels:')
      for c in valid_chan_list:
        print('channel {} output: {}'.format(c, GPIO.input(c)))
      level = int(raw_input('level: '))
      if chan in valid_chan_list:
          GPIO.setup(chan, GPIO.OUT)
          GPIO.output(chan, level)
        except(RunTimeWarning): # for the annoying pull-up resistor warning
And you asked if this happens to other pins. Not exactly, but I do have another issue with pins 4 and 14 (which I forgot to mention in my original post, as I was away from the Pi):
- when I set GPIO 14 to HIGH, within 30 seconds it pulls GPIO 4 to HIGH also. Even if I explicitly set GPIO 4 back to LOW, it will eventually go back HIGH if GPIO 14 is still set HIGH. This is only true in the LOW->HIGH toggle direction (i.e. if GPIO 14 is set LOW, it will not pull GPIO 4 low). This is perhaps even more of a problem than GPIO 27 (in fact, I only need 16 usable GPIO pins so I could leave 27 out if I can sort out the issue with 4 & 14)

Just FYI, I am an engineer and a fairly long-time Linux user and have done some embedded systems development, so *shouldn't* need the Noob filter here ;)

Thanks guys :)

Re: GPIO pin will not hold its output value

Posted: Sun Jun 21, 2015 8:50 pm
by ghp
really strange. The 21/27-GPIO was an obvious risk you excluded. Other GPIO are affected, they seem to depend from each other, this would indicate a hardware failure. But the problem is the same on another hardware. What is common ? SD-card, relay card, power supply ?
If SD the same, try setting up a new SD card from scratch. On my cards, there are so many experiments, that I do not always know what is in there.
When I understood correctly, the effect is independent whether relay card is connected or not. This would exclude defects in the relay card. In another post on this type of relais cards there was a hint on to check whether the high side of the optocouplers is to 5V or 3.3V. You could check this when disconnecting the GPIO and measure voltage on relais card input side.
Power supply: the relay card is opto coupled, I assume, so spikes from switching solenoids shouldn't come back. Different power supply for relais card ? Can't imagine power supply is only affecting GPIO and not stability of system as a whole.


Re: GPIO pin will not hold its output value

Posted: Mon Jun 22, 2015 5:39 pm
by tercel
Yes, strange indeed. I've decided just to implement a workaround for now, as I don't need all the pins right away (i.e. some watering zones don't yet exist). So I'm avoiding using the GPIO pins observed to have strange behaviour, and made my controller software re-write the GPIO output values periodically, in case any of them decide to change state for no good reason. This isn't the most elegant solution, but...

Regarding the SD card, I recently flashed a fresh Raspbian image to it and installed just the bare necessary libraries / packages for this application. And yes, you are right that these observed effects are independent of the relay card. I did use the same RPi power supply when testing the same SD+software in different Pi's, but I'm not sure how that would affect this (unless some really bad electrical noise from the switching?)

So I will probably revisit this issue in the future, but this "solution" will suffice for now. I really appreciate your suggestions in trying to help me track this down.