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:
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:
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.
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.
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.
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:
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):
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)?
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.
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.