GPIO Not Retaining State on Verdin iMX8MP with gpioset/gpioget

[prem0919]

I am working with the Verdin iMX8MP module and facing an issue where a GPIO does not retain its state after using gpioset.
Issue Details:

I am trying to set GPIO chip 3, line 14 using gpioset, but when I read back the value using gpioget, it always returns inactive (0).
The commands I am using:

gpioset -t 0 -c gpiochip3 14=1
gpioget -c gpiochip3 14

Expected output: 1 (active)
Actual output: inactive (0)

Some of the gpios in chip3 i am facing this issue.

[ToradexAI]

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

---

Hello,

I understand you’re encountering an issue with the Verdin iMX8MP module where a GPIO does not retain its state after using ‘gpioset’. Let’s go through some steps to help you troubleshoot and resolve this problem:

1. Verify GPIO Configuration: Ensure that the GPIO is correctly configured in the device tree. The GPIO line should not be assigned to any other peripheral or function that might override its state.

2. Check for Conflicts: Make sure no other process or service is accessing or modifying the state of the GPIO line. You can use tools like lsof to check for open file descriptors on the GPIO.

3. Use Correct Commands: Double-check the syntax of your ‘gpioset’ and ‘gpioget’ commands. The command gpioset -t 0 -c gpiochip3 14=1 should set the GPIO line 14 on chip 3 to active. The -t 0 option is used to set the line without a timeout, which is correct for retaining the state.

4. Kernel and Driver Support: Ensure that your Linux kernel and GPIO driver support the operations you are performing. Sometimes, specific kernel versions or configurations might have bugs or limitations.

If these steps do not resolve the issue, consider testing with a different GPIO line to see if the problem is isolated to a specific line or chip. This can help determine if the issue is related to the configuration or a broader system problem.

I hope this helps you resolve the issue. If you have any further questions, feel free to ask.

Best regards,
Toradex AI Assistant

Please, also check if these links can help you solve your problem:

Setting GPIO pin not working

Hello, We are currently using the Verdin IMX8MM DL 1GB WB IT with a custom board with some GPIO assignments. I cannot seem to control the GPIO output pins. We have buttons system and that works perfectly fine. But setting the GPIO programmatically does not work. I am using the gpiod library for python, like this: def __init__(self, hw_chip, offset, direction, default=0): """ Initiates HW GPIO. GPIO pins HW mapping can be seen by running "gpioinfo" command in the D…

Verdin iMX8M Plus GPIO pull up configuration

From I brand new iMX8M Plus board I need to use 4 GPIO lines: GPIO_1 - gpiochip0 pin 1 GPIO_2 - gpiochip0 pin 2 GPIO_3 - gpiochip0 pin 5 GPIO_4 - gpiochip0 pin 6 When booting up as default I’ve noticed thet GPIO_3 is pulled up (+1,8V), and the other inputs are not (0v). I need all 4 lines to be pulled up and I found out I need to customize the device tree, as libgpiod cannot set the pull up configuration for input - can someone help and please confirm that - that would be much easier to do it…

Why is USB_2_OC# a GPIO on Verdin IMX8MP.

[matthijs]

I suspect this might be due to the pinctrl configuration in the devicetree. IIUC, reading back the output of a pin is not supported by default, but only when the SION flag is configured to configure the driver: https://www.kernel.org/doc/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt

This flag is bit (1 << 30) == 0x40000000 in the pinctrl configuration.

It seems that in the default verdin devicetree, most pins do not have this flag configured, but for example the I2C pins do have it (probably so the driver can read back the pins to detect a stuck bus):

   /* On-module I2C */
   pinctrl_i2c1: i2c1grp {
    fsl,pins =
     <MX8MP_IOMUXC_I2C1_SCL__I2C1_SCL 0x400001c6>, /* PMIC_I2C_SCL */
     <MX8MP_IOMUXC_I2C1_SDA__I2C1_SDA 0x400001c6>; /* PMIC_I2C_SDA */
   };

Maybe the underlying question, though, is do you really need to read back the GPIO state? Or are you just using it to check if the gpioset works? If the latter, are you sure the gpioset did not work (i.e. did you measure the pin output)?

[prem0919]

Hi @matthijs ,
Yes, I need to read back the GPIO state after setting it. The issue I am facing is that even after setting the GPIO high using gpioset, gpioget still reads it as low, and the logic analyzer also confirms that the pin remains low.

In the provided screenshot we can see that some pins are changing the state as HIGH in the first attempt of getting the state using gpioset and further it is showing active LOW.
Please provide us a solution to resolve this case.

regards,
prem0919

[prem0919]

Hello Team,
Any inputs on this?

[lucas_az.tx]

Hi @prem0919!

This pin (SODIMM 217) is used by the second Ethernet PHY of Verdin Development Board. You cannot modify this pin if you are using the Verdin Dev Board device tree.

In order to set its value, you have to either change the device tree for another (Dahlia board, for example) or you have to write a device tree overlay disabling the node that reserves this pin.

Here you can find how to change the device tree, and if you want to write an overlay, this is the node that you must disable.

Best regards.
Lucas Azeituno.

[prem0919]

Hi @lucas_az.tx ,
Thanks for your reply.
I am already disabled &fec node in device tree,still we are facing the issue.

These are all the pins which are not changing their state.
But when i toggle using sysfs instead of libgpiod it is toggiling fine.

what could be the cause of this issue?

regards,
prem0919.