Unable to configure pin 134 as a GPIO pin on Colibri-imx6

Technical Support
, ,
1

Hi All.

We are wanting to configure pin 134 on our board for GPIO.

We consulted https://docs.toradex.com/102075-colibri-imx6-datasheet.pdf, and (if not wrong) found on page 16 that pin 134 corresponds to NAND_DATA01.

So, we added MX6QDL_PAD_NANDF_D1__NAND_DATA01 in pinctrl_gpio_1 in arch/arm/boot/dts/imx6qdl-colibri.dtsi, re-compiled and flashed the latest uImage and imx6dl-colibri-eval-v3.dtb

Thereafter, following is done after boot, and observed :

cd /sys/class/gpio
echo 134 > export
echo out > gpio134/direction
echo 1 > gpio134/value
cat gpio134/value
0

As is seen, gpio134/value still emits a 0.

What are we missing?

Please find the relevant files here
Will be grateful for pointers.

Thanks and Regards,
Ajay

2

Update :

Upon seeing page 26, it is seen that pin 134 also corresponds to GPIO2_IO01.

GPIO2_IO01 is already exported as a gpio pin, so I re-compiled and flashed, and ran the following commands upon boot :

cd /sys/class/gpio
echo 33 > export
echo out > gpio33/direction
echo 1 > gpio33/value
cat gpio33/value

Unfortunately, again a 0 is emitted.
The revised set of (relevant) files are here.

Kindly let know what am I doing wrong?

3

Which version of the BSP are you using?

4

Hi Stefan.

Thanks for the reply.
We are using Colibri Eval 3.1.

5

That is the Carrier Board.

With BSP (Board Support Package) I mean the software version runnign on the module. You can check e.g. by using cat /etc/issue.

6

Yes, pad NAND_DATA01 has a mux option of GPIO2_IO01, which we set by default in our device tree. GPIO2_IO01 translates to GPIO 33, so you should be able to control the pad using GPIO 33.

I tested this here by connecting X3-B23 to LED1 on the carrier board. The LED seem to turn on/off and reading back the value seems to work too:

root@colibri-imx6:/sys/class/gpio# cd /sys/class/gpio
root@colibri-imx6:/sys/class/gpio# echo 33 > export
root@colibri-imx6:/sys/class/gpio# echo out > gpio33/direction
root@colibri-imx6:/sys/class/gpio# echo 1 > gpio33/value
root@colibri-imx6:/sys/class/gpio# cat gpio33/value
1
root@colibri-imx6:/sys/class/gpio# echo 0 > gpio33/value
root@colibri-imx6:/sys/class/gpio# cat gpio33/value
0
7

Oops, sorry Stefan for the inconvenience.
Here is the version :

root@colibri-imx6:~# cat /etc/issue
.---O---.                                           
|       |                  .-.           o o        
|   |   |-----.-----.-----.| |   .----..-----.-----.
|       |     | __  |  ---'| '--.|  .-'|     |     |
|   |   |  |  |     |---  ||  --'|  |  |  '  | | | |
'---'---'--'--'--.  |-----''----''--'  '-----'-'-'-'
                -'  |
                '---'

The Angstrom Distribution \n \l

Angstrom v2016.12 - Kernel 

Colibri-iMX6_LXDE-Image 2.7b4 20171005
8

Hi stefan.

Thanks for the reply.

Yes, that’s what I expect too.
However, the value is always emitted as 0

Just two queries :

a)
We have enabled can1 and can2 in the device-tree. I hope it does not conflict with anything.

b)
Also, right now we have not connected any LED or anything. I hope it is not a necessity.

Thanks again, I will also consult the hardware engineer and see if he can throw some light on it.

Thanks and Regards,
Ajay

9

can1/2 should not influence operation of that GPIO since they are using a different pads.

Having connected nothing should be fine too. As long as it is not tied to ground or 3.3V it should work…

Note, the default mux already muxes to GPIO2_IO1, see arch/arm/boot/dts/imx6qdl-colibri.dtsi, the pinmux group pinctrl_weim_gpio_1. Adding MX6QDL_PAD_NANDF_D1__NAND_DATA01 is really harmful since that will mux the pin to a NAND function!

10

Yes stefan, I have already seen the pictrl_weim_gpio_1, and also I have already reverted the MX6QDL_PAD_NANDF_D1__NAND_DATA01 change in the device-tree, and flashed with the re-compiled dtb and uImage; however, I still get a 0 everytime.

Still waiting for the hardware engineer to spare some time for me :expressionless:

Thanks again stefan.

11

You can also check sysfs whether muxing has been successfully applied using the group you intended to use for that pin:

# cat /sys/kernel/debug/pinctrl/pinctrl-handles  | grep NANDF_D1 -C 10
Requested pin control handlers their pinmux maps:
device: 20e0000.iomuxc current state: default
  state: default
    type: MUX_GROUP controller 20e0000.iomuxc group: weim_gpio-1 (51) function: weim (14)
    type: CONFIGS_PIN controller 20e0000.iomuxc pin MX6DL_PAD_KEY_ROW2     (152)config 0001b0b0
    type: CONFIGS_PIN controller 20e0000.iomuxc pin MX6DL_PAD_KEY_COL2 (147)config 0001b0b0
    type: CONFIGS_PIN controller 20e0000.iomuxc pin MX6DL_PAD_NANDF_D1 (162)config 0001b0b0
12

Hi stefan.

I guess the output is fine at my end too :

root@colibri-imx6:~#  cat /sys/kernel/debug/pinctrl/pinctrl-handles  | grep NANDF_D1 -C 10
Requested pin control handlers their pinmux maps:
device: 20e0000.iomuxc current state: default
  state: default
    type: MUX_GROUP controller 20e0000.iomuxc group: weim_gpio-1 (51) function: weim (14)
    type: CONFIGS_PIN controller 20e0000.iomuxc pin MX6DL_PAD_KEY_ROW2 (152) 0001b0b0
    type: CONFIGS_PIN controller 20e0000.iomuxc pin MX6DL_PAD_KEY_COL2 (147) 0001b0b0
    type: CONFIGS_PIN controller 20e0000.iomuxc pin MX6DL_PAD_NANDF_D1 (162) 0001b0b0
    type: MUX_GROUP controller 20e0000.iomuxc group: weim_gpio-2 (52) function: weim (14)
    type: CONFIGS_PIN controller 20e0000.iomuxc pin MX6DL_PAD_DISP0_DAT23 (60) 0001b0b0
    type: CONFIGS_PIN controller 20e0000.iomuxc pin MX6DL_PAD_DISP0_DAT22 (59) 0001b0b0
    type: CONFIGS_PIN controller 20e0000.iomuxc pin MX6DL_PAD_DISP0_DAT21 (58) 0001b0b0
    type: CONFIGS_PIN controller 20e0000.iomuxc pin MX6DL_PAD_DISP0_DAT20 (57) 0001b0b0
    type: CONFIGS_PIN controller 20e0000.iomuxc pin MX6DL_PAD_DISP0_DAT19 (55) 0001b0b0
    type: CONFIGS_PIN controller 20e0000.iomuxc pin MX6DL_PAD_DISP0_DAT18 (54) 0001b0b0
    type: MUX_GROUP controller 20e0000.iomuxc group: weim_gpio-3 (53) function: weim (14)
    type: CONFIGS_PIN controller 20e0000.iomuxc pin MX6DL_PAD_EIM_LBA (117) 0001b0b0
    type: CONFIGS_PIN controller 20e0000.iomuxc pin MX6DL_PAD_EIM_BCLK (78) 0001b0b0
13

I agree, this looks correct. I recommend checking hardware…

14

That was it jaski …

diff --git a/arch/arm/boot/dts/imx6dl-pinfunc.h b/arch/arm/boot/dts/imx6dl-pinfunc.h
index 0ead323..aedc4cd 100644
--- a/arch/arm/boot/dts/imx6dl-pinfunc.h
+++ b/arch/arm/boot/dts/imx6dl-pinfunc.h
@@ -887,7 +887,7 @@
 #define MX6QDL_PAD_NANDF_D0__GPIO2_IO00             0x284 0x66c 0x000 0x5 0x0
 #define MX6QDL_PAD_NANDF_D1__NAND_DATA01            0x288 0x670 0x000 0x0 0x0
 #define MX6QDL_PAD_NANDF_D1__SD1_DATA5              0x288 0x670 0x000 0x1 0x0
-#define MX6QDL_PAD_NANDF_D1__GPIO2_IO01             0x288 0x670 0x000 0x5 0x0
+#define MX6QDL_PAD_NANDF_D1__GPIO2_IO01             0x288 0x670 0x000 0x15 0x0
 #define MX6QDL_PAD_NANDF_D2__NAND_DATA02            0x28c 0x674 0x000 0x0 0x0
 #define MX6QDL_PAD_NANDF_D2__SD1_DATA6              0x28c 0x674 0x000 0x1 0x0
 #define MX6QDL_PAD_NANDF_D2__GPIO2_IO02             0x28c 0x674 0x000 0x5 0x0

Thanks a ton !!
And many, many more thanks to stefan for your quick and crisk help throughout !!

Thanks again rockstars !!

Thanks and Regards,
Ajay

15

It could be that the SION bit is not set for you, there are a bunch of answers to that topic in the community.

If that bit is not set you cannot read back the value of a GPIO configured as output, i.e. it will always read 0 independ off the current pin state.

16

Hi Ajay

Great that it worked for you.

Note that rather than changing the generic file imx6dl-pinfunc.h I would set the SION bit as it is done e.g. for the ENET_REF_CLK in the device tree:

MX6QDL_PAD_GPIO_16__ENET_REF_CLK	((1<<30) | 0x1b0b0)

Max

17

Thanks a ton max !!

Reverted the previous change, and made the change in
arch/arm/boot/dts/imx6qdl-colibri.dtsi

Thanks again …

Thanks and Regards,
Ajay