Home/Support/Support Forum/Why can't I control EXP_GPIO_1 (GPIO1_5)
Welcome to Digi Forum, where you can ask questions and receive answers from other members of the community.

Why can't I control EXP_GPIO_1 (GPIO1_5)

0 votes
I have a ConnectCore 6UL Pro. I can control all of the GPIO's that I need except for this one - GPIO1_IO05. I checked the device tree and it seems that this GPIO is in fact available on the pin. I've tried this on two boards with the same results. I've used both sysfs and C code. Sysfs shows the bit value toggling but the pin doesn't change.
Perhaps I have interpreted the pin assignments improperly?
asked Jul 26 in Linux by jstodhunter New to the Community (1 point)
Thanks - as soon as I saw that the pin was in the pwm group, I got it.  Thanks for such a quick response.

Please log in or register to answer this question.

1 Answer

+1 vote
Are you are using stock images? If so please take a look at stock device tree:
https://www.digi.com/resources/documentation/digidocs/embedded/dey/2.6/cc6ul/bsp_r_device-tree-files


it will link you to the actual file here:

imx6ul-ccimx6ulsbc.dtsi
Common hardware for ConnectCore 6UL SBC Pro


https://github.com/digi-embedded/linux/blob/v4.14/dey-2.6/maint/arch/arm/boot/dts/imx6ul-ccimx6ulsbc.dtsi


search for GPIO1_IO05 and at line 623 you will find a definition:

pinctrl_pwm4: pwm4grp {
fsl,pins = <
MX6UL_PAD_GPIO1_IO05__PWM4_OUT 0x110b0
>;
};


As you can see - in the stock images this pin is configured as PWM and not GPIO. You'd have to build your own images commenting out this code.
You can probably verify my theory by trying to use this pin as PWM4 on stock images using instructions here:
https://www.digi.com/resources/documentation/digidocs/embedded/dey/2.6/cc6ul/bsp_r_pwm_6ul

The default muxing of the pads is specified in the i.MX6ul reference manual. Almost all of them default to GPIO. Off the top of my head, I remember the JTAG pads as the exception, those are configured as JTAG (not GPIO) by default. I think those are the only exception. So commenting out code above should be enough to restore that pin function back to GPIO.

However, it is still a good idea to explicitly define it as GPIO

/* General purpose pinctrl */
imx6ul-ccimx6ul {
pinctrl_hog: hoggrp {
fsl,pins = <
MX6UL_PAD_GPIO1_IO0GPIO1_IO05__GPIO1_IO05 0x10b0
>;
};
};
};

This way you will get a compile-time warning if you try to use the same pin twice.
answered Jul 27 by LeonidM Veteran of the Digi Community (4,355 points)
...