Hello,
I have an i.MX7D on a colibri board, and I have problems using GPIO.
when I do :
echo XX > /sys/class/gpio/export
echo “out” > /sys/class/gpio/gpioXX/direction
echo 1 > /sys/class/gpio/gpioXX/value
Nothing happens whatever XX is (55, 45, 106 etc). I can’t read or write on any GPIO port… And I have no error…
It looks like something is stuck in a strange state. Because for example GPIO 106 is always HIGH.
Any ideas ?
Thank you for your help.
GPIO sysfs interface controls only the GPIO peripheral not the pinmuxing, that’s why it will be available for all gpios not in use by kernel. If you want to use a particular pin you’ll have to make sure that it’s muxed appropriately in the devicetree. if you just want to test GPIOs, some (like pins 133 (linux gpio no. 58) and 127 (linux gpio no. 58) of the colibri module) are already muxed as GPIOs and can be used without modifications to the devicetree.
Information on imx7 pinmuxing:
Thank you for your response.
Yes I know all of that, but in this document page 20 we can see that gpio5.IO[14] is the reset state of the pin 23 of X1.
So it is the SODIMM_142, but nothing happened when I try to toggle a LED.
For example I already got the SODIMM_105/106 working but now they seemed blocked in their current state. Same with 133 and 127…
pin 23 of X1 is SODIMM_23 not SODIMM_142. gpio5.IO[14] in linux has an id of 142. I just checked it with our latest BSP and it works as expected.
Are you using custom image? What carrier board do you use?
Ok it seems I mixed up all the IDs… How can I found easily the matching between the sodimm numbers and the linux id ?
You can use modules datasheet to get from module edge connector (X1, SODIMM) to gpio name eg. X1 23 (SODIMM_23) → gpio5.IO{14] then you can calculate it with:
32 x (controller- 1) + gpio => 32 * (5 - 1) + 14 = 128 + 14 = 142
or look it up on:
GPIO Alphanumeric to GPIO Numeric Assignment | Toradex Developer Center
Thank you !
