GPIO output value not changing.

[kylekenj]

I am trying to setup up a output GPIO pin on my Nitrogen6X board, but I can't change the file value. I navigated to /sys/class/gpio/ and I exported my pin (GPIO18) with echo 18 > export. I was then able to change direction with the command echo out > direction and it seems like I should be able to change the value file the same way, with echo 1 > value, but this doesn't seem to be working. I am logged in as root and the permissions on both the direction file and the value file are the same: -rw-r--r-- 1 root root.

Does anyone have an idea why this would not be writing to this file?

Thanks so much for all of your help!

[namratanalawade]

I have same issue with imx6sl evk with kernel 4.1.15. I am trying to use mx6sl_pad-d5_gpio1_io12 as gpio by adding entry in DTS file in hoggrp.

I can export the gpio12 from user space, but its value does not change when i use echo 1/0,it always returns 0. I'm stuck here,please help.

a quick help would be appreciated.

[nedeljkoradulov]

Hi,

I am having a problem controlling gpio16(gpio7_IO11) in Ubuntu 14.04 on a custom board based on Sabre SDB.

I tried following procedure:

echo 203 > /sys/class/gpio/export

/sys/class/gpio/gpio203

# Changing pin direction
echo in > /sys/class/gpio/gpio203/direction
echo out > /sys/class/gpio/gpio203/direction

# Toggling GPIO output level
echo 0 > /sys/class/gpio/gpio203/value
echo 1 > /sys/class/gpio/gpio203/value

But it didn't work. When I read gpio value I get random 0 or 1.

Does anybody has an idea what could be wrong?

Best regards,

Nedeljko

[byungchul]

Please, check it first that gpio is used kernel inside.

if so, you have to free using by gpio_free(??).

Although you can develop your own driver to control GPIOs inside kernel space, there is a much simpler way for accessing GPIOs from user space.

When timing requirements are not an issue, you are able to use GPIO-SYSFS.

SYSFS is a virtual file system that exports some kernel internal framework functionalities to user space and GPIO is one of the frameworks that can have functionalities exported through SYSFS.

The GPIO-SYSFS feature is available in all mainline kernels from 2.6.27 onwards.

Configuring Kernel to export GPIO through SYSFS

To enable GPIO in SYSFS, select the following kernel option:
Device Drivers --->
      --- GPIO Support
            [*] /sys/class/gpio/... (sysfs interface)

Be sure that the pins you will try to use are really accessible as GPIO pins and were not requested by the kernel (gpio_request).
If pin was gpio_request'ed, you will need to gpio_export the same pin inside the kernel in order to have it accessible through SYSFS.
If pin is not set as GPIO by default, you will need to set IO MUX in the proper file inside <kernel>/arch/arm/mach-XXX.

Accessing GPIO in user space

After enabling GPIO-SYSFS feature, you can boot your device with the new kernel to make some tests.

First you need to export the GPIO you want to test to the user space:
BUZZER GPIO(4,28) - (4-1)*32 + 28

echo 124 > /sys/class/gpio/export

XX shall be determined by the following algorithm:
GPIOA_[B] is the GPIO you want to export, where "A" is the GPIO bank and "B" is the offset of the pin in the bank.

if the first available GPIO bank is 0 // (iMX.6, for example)
    XX = A*32 + B;
else // first GPIO bank is 1
    XX = (A-1)*32 + B;

After exporting a GPIO pin, you shall be able to see the GPIO interface exported to:
/sys/class/gpio/gpio124

Through this interface, you are now able to do things like:
# Reading the pin value
cat /sys/class/gpio/gpio124/value

# Changing pin direction
echo in > /sys/class/gpio/gpio124/direction
echo out > /sys/class/gpio/gpio124/direction

# Toggling GPIO output level
echo 0 > /sys/class/gpio/gpio124/value
echo 1 > /sys/class/gpio/gpio124/value

[ericchristensen]

I have done all this.  And it seems to work fine until I try: echo 1 > /sys/class/gpio/gpio124/value. 

This does not seem to be working because when I type: cat /sys/class/gpio/gpio124/value it still returns '0.'  Any ideas what could still be causing this problem?

[lategoodbye]

Hi Eric, varsmolta is right.

Have a look at this discussion: imx.6 GPIO

[varsmolta]

I vaguely remember that if you cat the file after writing to it, you may not see the value change, though the GPIO may be toggling correctly. The only way to be sure is to probe the GPIO with an oscilloscope or attach an LED to the pin

[ericchristensen]

Ok, Thanks for the information.  One final question however.  It seems like each of the GPIO pins has two different names, for example, I saw somewhere that GPIO_18 is ALSO GPIO7_13... so we would want to export (7-1)*32 + 13 or 205.  My question however, is where does this come from?  Where can we find that it is GPIO7_13.  I have a number of GPIO pins I could probe but I need to know what pin numbers I should export.  Can someone show me exactly where I would find that? 

Thanks!

[varsmolta · Accepted solution]

Look at Sec 4 of the i.mx6 reference manual: 4. External Signals and Pin Multiplexing. The table here gives you the mapping between the pad name (in your example, this is GPIO_18) to the signal name (in your example, GPIO7_13).

[varsmolta]

is that I/O pin configured for GPIO in the pinmux configuration? look at this file: linux-imx6/arch/arm/mach-mx6/pads-mx6_nitrogen6x.h at boundary-imx_3.0.35_4.0.0 · boundarydevices/li.... You should be able to confirm if it is for your case. If not, change the file and recompile the kernel.

Question for someone else is: Is there a way to do this from user-space without recompiling the kernel?

[ericchristensen]

Hi, I am having the same exact issue.  What would a good gpio be to use that has the correct pinmux configuration by default?  And where do I pull that off of the pin from?

[varsmolta]

According to the Nitrogen6x manual, the "button" gpios are already configured with the correct pinmux (linux-imx6/arch/arm/mach-mx6/pads-mx6_nitrogen6x.h at boundary-imx_3.0.35_4.0.0 · boundarydevices/li...). They are on  the J14 connector of the Nitrogen 6x. You can use the GPIO_SYSFS approach (see byungchul's response) to test it