Trouble getting GPIO12 to go high

[esteimle]

I'm trying to drive GPIO12 on a PI 2 Zero high but it's always low. I was able to control GPIO26 using pigpio in c++

gpioSetMode(26, PI_OUTPUT); // Set GPIO26 as output.
gpioWrite(26, 1); // Set GPIO26 high.

But when I try
gpioSetMode(12, PI_OUTPUT); // Set GPIO12 as output.
gpioWrite(12, 1); // Set GPIO12 high.

It always stays low. I'm looking at the header pin with a scope too.

I thought maybe I had the wrong fsel setting but it seems to match what I see for gpio26. But even here you can see the level always stays low for some reason.

The output of raspio get 12 is:
GPIO 12: level=0 fsel=1 func=OUTPUT

Where as the output of raspio get 26 is:
GPIO 26: level=1 fsel=1 func=OUTPUT

Am I missing something? Maybe because this is a PWM pin I have to treat it differently? Or maybe I have to set the function select for this pin somewhere else like a device overlay or something?

Any advice is appreciated.

Thank you

[cleverca22]

Am I missing something? Maybe because this is a PWM pin I have to treat it differently?

if it was in pwm mode, then the fsel from "raspio get 12" would have said so

how are you connecting to that pin? do you have photos?

[B.Goode]

I'm trying to drive GPIO12 on a PI 2 Zero high but it's always low. I was able to control GPIO26 using pigpio in c++

[ ... ]

Any advice is appreciated.

Have you tried replicating the issue using the pigs CLI interface to the pigpio daemon?

https://abyz.me.uk/rpi/pigpio/pigs.html

[DougieLawson]

Are you sure you're looking at the right pin?

https://pinout.xyz/pinout/pin12_gpio18
https://pinout.xyz/pinout/pin32_gpio12

[thagrol]

Which pin numbering scheme are you using? The broadcom GPIO ID, the physical pin number, wiringpi? It will make a difference.

[esteimle]

Thanks for all the replies. I'm probing with an oscilloscope probe right here: https://pinout.xyz/pinout/pin32_gpio12 The probe ground is connected to ground.

When I do this with GPIO_26 everything works fine.

I did not try pigs, but I'm not using the dameon approach. I'm just controlling it directly from my application.

[rpdom]

I'm wondering if your code is clearing the level somewhere, or doing some sort of gpio cleanup.

If you set the level from the command line with raspi-gpio, what does it show?

This is what I get on a Zero 2W with Raspi OS Bullseye Lite 32-bit with 64-bit kernel

Code: Select all

notpi@cam2:~ $ raspi-gpio get 12
GPIO 12: level=0 fsel=0 func=INPUT
notpi@cam2:~ $ raspi-gpio set 12 op dh
notpi@cam2:~ $ raspi-gpio get 12
GPIO 12: level=1 fsel=1 func=OUTPUT

and test the level of the pin output.

[B.Goode]

I did not try pigs, but I'm not using the dameon approach. I'm just controlling it directly from my application.

My suggestion was based on the idea that by using pigs or the supplied gpiotest utility you would be checking @joan's pigpio implementation and your own GPIO hardware independently of your own application code.

[aBUGSworstnightmare]

another idea is using config.txt.
As OP states he/she has checked GPIO26 I've added it to the test scheme as well

# configure selected pin to output, set LOW
#gpio=xx=op,dl
# configure selected pin to output, set HIGH
#gpio=xx=op,dh

So for GPIO12=LOW and GPIO26=HIGH add below to your config.txt and reboot. Then measure the result or use 'raspi-gpio get' to see which level they have

Code: Select all

# configure selected pin to output, set LOW
#gpio=12=op,dl
# configure selected pin to output, set HIGH
#gpio=26=op,dh

now crosscheck them configured the other way around by changing config.txt to belo and reboot. Reheck the result.

Code: Select all

# configure selected pin to output, set LOW
#gpio=26=op,dl
# configure selected pin to output, set HIGH
#gpio=12=op,dh

Report back