GPIOCHIP4 Line 12 SODIMM 116 cant be set HIGH

I’m doing some tests, I have an enable signal for a circuit thats meant to be driven by GPIO14 which is SODIMM 116 GPIO5_IO12 (aka GPIOCHIPO4 Line 12 in Linux).
When i try to set the pin high using

gpioset /dev/gpiochip4 12=1

The pin doesnt go HIGH as expected, it remains LOW.

On a fresh boot gpio info shows the pin as

line  12: "SODIMM_116"       unused   input  active-high

But after applying the gpioset command it shows as

 line  12: "SODIMM_116"       unused  output  active-high

But the pin is remaining low.
When I then check GPIOGET on the pin, it shows as 1 but the pin remains LOW on my scope.

I’m not really sure what else to try. I’m not really a Linux developer I’m a hardware developer, I’m not setup to change device trees… What are my other options?

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

Did you like my answer? :+1: :-1:


Hello! Thank you for reaching out with your question.

The behavior you’re observing likely means that GPIO5_IO12 (SODIMM 116) is not properly configured as a GPIO in the device tree. Even though the gpioset and gpioinfo tools report the direction and value changes, the pin will not respond at the hardware level unless it is correctly muxed for GPIO use in the device tree.

Immediate Troubleshooting Steps

Since you mentioned you’re not set up to change device trees, your quickest option is to use a different GPIO pin that is already configured for GPIO use.

You can check which GPIO pins are available and ready by running:

gpioinfo | grep -e "SODIMM" -e "MXM3"

This command will help you identify which pins are available and already properly muxed for GPIO usage. Try using one of those pins for your enable signal.

References:

Why is Device Tree Change Needed?

The pin remains LOW because, by default, it may be set up for another hardware function, not pure GPIO. In such a case, Linux userspace tools will not generate errors but also won’t affect the pin state.

“it is important to make sure that the pin is actually muxed as a GPIO in the device-tree or platform data. Failing to do so will not give any error. The pin will simply report 0 if configured as an input and not react to any state change if configured as an output”

Toradex GPIO Linux Documentation

If You Must Use SODIMM 116

If you absolutely need to use SODIMM 116 (GPIO5_IO12), you will need to create a device tree overlay that muxes the pin to GPIO mode. Overlays allow making such changes without building a custom kernel. Toradex provides documentation that can help you get started with this process if you decide to set up for device tree changes in the future.

Summary

  • Quick workaround: Use a different GPIO pin already configured and available.
  • Permanent solution for this pin: Create a device tree overlay to properly configure SODIMM 116 as GPIO (recommended for production).

Further reading and references:

Let me know if you need help identifying possible alternative pins or if you’d like more step-by-step guidance on overlays!

Best regards,
Toradex AI Assistant.

Hello @Simon_RN,

First of all, sorry for the delayed answer here.

I tried to reproduce this behavior here on my side but realized that I do not have access to SODIMM_116 on any of the GPIO pins on a standard verdin iMX8MP and Verdin development board. I am using Toradex BSP 7. Could you please tell me what HW and SW setup you have?

Do you have a custom carrier board? Which BSP/Torizon version are you using? Have you enabled any device tree overlays at the moment?

It looks like the pin might be under the control of another subsystem. I need more details to dig into this.

Hi Rudhi,
Apologies for not updating the thread sooner, I got to bottom of the issue, and it was caused by the the fact we have the wifi version of the toradex. I now realise these pins are reserved for the wifi card wake and bt wake signals.
In our case this is causing a conflict and we cant use this pin. I have since bodged in an alt pin to use for the signal.

But thank you for reminding me to close the thread.

Hello @Simon_RN,

Glad to hear that you could solve it. Thanks for the update.