GPIO hangs CPU

[Nuncio]

I've just started experimenting with my RPi and I'm finding some odd behavior. Going by lots of examples I'm reading about, I'm attaching a switch to a GPIO pin. In my code I set up the GPIO as an input pulled high. Whenever I press the button (bringing the GPIO input to ground), the processor hangs. As soon as I release the button it resumes running just fine.
Is there anything I'm missing hooking up a button to a GPIO pin?
I also noticed if I change the code to configure the GPIO as an input pulled low, as soon as the program starts, the processor hangs until I press the button to bring the GPIO high.
What's going on?

[joan]

Which gpio pin are you using? Could you indicate what is connected to what?

[Nuncio]

Which gpio pin are you using? Could you indicate what is connected to what?

It doesn't seem to matter which GPIO. I'm using P1-15 (GPIO22) at the moment.
I'm finding I can't actually bring the GPIO to ground. If I bring it down around 1V I'm seeing better operation, although occasionally I'm seeing a logic 1 while the button remains pressed.
I have revision 2 of the board (P5 is available), but I'm hoping there isn't too much difference between board revs that this would make a difference.

Something that's currently working is to connect P1-15 to button, and the other side of the button is split - 10K ohm to 3.3V and 4.7K to ground. I should probably use a 2.2K to get down to about 0.6V

I didn't realize the RPi GPIO inputs were so sensitive.

[joan]

I'd connect the other end of the switch to ground or 3.3V, not both.

I assume you have some software running to monitor the gpio. Perhaps the software is causing the hang.

[cyrano]

What value is you pull-up resistor?

[jojopi]

I also noticed if I change the code to configure the GPIO as an input pulled low, as soon as the program starts, the processor hangs until I press the button to bring the GPIO high.

Surely that proves that it is your code that hangs (more likely, spins) the processor, not the GPIO.

[Nuncio]

I don't even need code running. Connecting any GPIO to ground stops the processor. Doesn't matter what GPIO. As long as it's set up as an input. I've seen this on two different boards now.

[jojopi]

I don't even need code running. Connecting any GPIO to ground stops the processor. Doesn't matter what GPIO. As long as it's set up as an input. I've seen this on two different boards now.

Firstly, I misinterpreted your results. They do not prove a software problem in the way that I thought.

I am still more interested in the second test because it does not involve touching the hardware. So it is both safer and easier to debug remotely.

Basically you were saying that enabling weak pull-down in software was enough to create the "hanging" effect, just the same as physically pulling the pin down? What language/library are you using for this, and can you post the code?

Are you certain that you are enabling weak pulls on an input pin, and not driving the pin as high/low output? If you are driving the pin one way in software and tying it the other way in hardware then you will draw excessive current. I would not expect that the reversible hang that you describe, but I would expect it to damage the GPIO.

Only if your second test works with nothing connected to P1: try changing the code to enable the pull-down and then immediately exit. What are the precise symptoms of the hang? Does the program not exit until you physically pull the pin high again, or does the prompt return but you cannot type? In other words, it may be USB that is failing, not the CPU.

[Nuncio]

I should have mentioned - I'm using the bcm2835-1.25 library to control the RPi.
I'll have to try making some code to just pull down the GPIO as an output and see what happens when I have a bit of time this afternoon...

[Nuncio]

After resetting the board and retrying a couple previous tests, I'm finding it's not a hardware problem.
I can definitely poll the GPIO using bcm2835_gpio_lev() and it gets the right value immediately. I can set the GPIO as pull up or down (with hardware connected the right way).
There seems to be a problem in bcm2835_gpio_len() in the bcm2835 library such that low detect enable checking hangs while the GPIO is brought low.

Doing a search on the low-detect enable routine I mentioned, I found another link to these forums:
http://www.raspberrypi.org/phpBB3/viewt ... 6&p=223528

This seems to be a problem in the kernel, so from now on I'll just do polling via bcm2835_gpio_lev()

Thanks for the help

[pjc123]

There seems to be a problem in bcm2835_gpio_len() in the bcm2835 library such that low detect enable checking hangs while the GPIO is brought low.

You could have just read the instructions (and CAUTION) on the front web page of the bcm2835 library as this is a known issue, and I quote:

"Tested on debian6-19-04-2012, 2012-07-15-wheezy-raspbian and Occidentalisv01 CAUTION: it has been observed that when detect enables such as bcm2835_gpio_len() are used and the pin is pulled LOW it can cause temporary hangs on 2012-07-15-wheezy-raspbian and Occidentalisv01. Reason for this is not yet determined, but suspect that an interrupt handler is hitting a hard loop on those OSs. If you must use bcm2835_gpio_len() and friends, make sure you disable the pins with bcm2835_gpio_cler_len() and friends after use."

[Nuncio]

Thanks for pointing that out after the fact!

[pjc123]

Thanks for pointing that out after the fact!

Lesson learned. RTFM. I wasn't so lucky, as that warning was not available when the library was first released many moons and revisions ago.