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.
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:
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)?
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
Hello Team,
Any inputs on this?
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.
Hi @lucas_az.tx ,
Thanks for your reply.
I am already disabled &fec node in device tree,still we are facing the issue.
what could be the cause of this issue?
regards,
prem0919.
Hi @prem0919!
Have you tried to measure the pin using a multimeter? I was doing some tests using libgpiod, and the behavior of the pin when I used gpioget was a little bit confusing. So I recommend using a multimeter instead of the command line, which can only be done if you are using a custom board, since these pins are not exposed in our boards.
Another thing, are these pins mandatory for your project? As I said, these pins are not exposed in our Verdin Carrier Boards, so it is more difficult to measure them. If you could use another GPIOs, it would probably be easier to work with, and our SoMs already have pins as GPIOs by default.
Another way to test these pins is to connect one GPIO to another GPIO and set the first to 1 and the second as input, and then try to read the signal on the second one by using the gpioget command.
Best regards.
Lucas Azeituno.
Hi @lucas_az.tx ,
we are having the custom board and,
I have tested the each pin with oscilloscope,while changing the state by the command line using libgpiod.But the pins are not retaining there state even after given the logic “1”.But when i do with the sysfs i.e; /sys/class/gpio/ i can see that the pins are retaining their states and also checked with the oscilloscope.
regards,
prem0919
Yes @lucas_az.tx , These pins are mandatory for our project.
Isn’t it expected in libgpiod3? I think older libgpiod versions retained pin state. Now process kind of owns changes made to GPIO and returns on exit to former state.
