I cut/paste a related information exchange I had w/ Kent from the gpiod mailing list. The arbian-monitor output is in the attached file.

>>>>>>>>

I wired a GPIO Pin to GND. Upon the cmd: sudo gpiomon -r -n1 -Bpull-up <chip> <offset> the program exits immediately with 1 event, although there was never a rising edge due to the fix wire to GND. Is this a feature or a bug, and is it reproducible?

<

Not a feature and not reproducible for me on a Raspberry Pi4 with the setup you describe, so probably a bug specific to your hardware platform, whatever that may be. If it is 100% reproduceable for you, and assuming it is an initialisation issue so you only get the one spurious event, how about using -n2 as a workaround ? Cheers, Kent.

>

It appears 2b reproduceable 100% on my OrangePi zero+ (Allwinner H5) and using -n2 does the trick, but isn't gpiod not supposed to work on all commercial HW platforms and related kernels, rather then only on RPI??

<

gpiod will work on any platform with a supporting kernel. How well depends on the underlying hardware and driver. The RPi4 was merely a counter-example demonstrating that your issue is not universal, using hardware I happen to have readily available. Cheers, Kent.

>

So if I understand you right, gpiod works on sort of a logical level, while the HW dependend part depends of the kernel driver implementation of the specific HW?

<

libgpiod is a userspace library and tools to access GPIO lines via the Linux GPIO character device. The actual interfacing to the hardware is performed by the kernel and appropriate drivers for your hardware. As your problem does not exhibit on other hardware, the root cause of your problem probably lies in the driver for your hardware, not in libgpiod nor the gpiolib subsystem of the kernel. But you would need to debug it further to be sure. Cheers, Kent.

 

* Event should be more correct than Interrupt.

 

I made some trial to understand if it is reproduceable, but I have difficulties defining, when it happens. After RESET there is no spurious event. The spurious event appears to happen, when the line was moved:

RESET, gpiomon -r -n1 -Bpull-up 1 6   => No event,  -> pull line up /down, => event (as expected),  gpiomon -r -n1 -Bpull-up 1 6 => false event

There might be an issue w/ pending interrupts, when the line is bouncing when pulled up/down. The 2nd gpiodmon cmd might catch one of the pending interrupts. (Just an idea). This would hint to an initialisation problem, that pending line states are not preempted, before the int is attached.

If I just let the line go up (by pull-up) and leave it "1", I get continuous false events on every gpiomon... cmd, just like "level interrupts"

 

Kent Gibson and I performed checks independently on our RPIs and we both can confirm that the problem does no occur on the RPI: Linux raspberrypi 5.10.63-v7+ #1459 SMP Wed Oct 6 16:41:10 BST 2021 armv7l GNU/Linux

 

 

armbian-monitor-U.txt

Hello, again,

Nobody feeling responsible for this??

When this issue would be solved, gpiod V. 1.65 +newer could indeed become an acceptable utility replacing the depreciated sysfs feature for future development.

RGDS

hk

@going do you have any ideas?

Just a thought.  How do you define what type of interrupt is used. (rising edge, falling edge, high or low)?
Is this a device tree thing?
Regards Kat

Let me more precise; pse follow the following simple recipe w/ gpiod  V1.65+ installed:

Power up

Connect 1 Pin of your choice to GND using a patch wire

Exe: sudo gpiomon -r -n1 -Bpull-up <chip> <offset>  //  rising edge, pull-up, exit after 1 event

expected behavior: cmd should "hang" and wait for rising edge @ Pin

Pull the wire

expected behavior: cmd should exit w/ event and timestamp

Reconnect the patch wire to ground, then

Exe: sudo gpiomon -r -n1 -Bpull-up <chip> <offset>

expected behavior: cmd should "hang" and wait for rising edge @ Pin

failure: cmd exits immediately w/ false event and timestamp although there was no rising edge (Pin was wired to GND)

Exe the same cmd a 2nd time w/out having touched the wire: sudo gpiomon -r -n1 -Bpull-up <chip> <offset>

expected behavior: cmd should "hang" and wait for rising edge @ Pin

Now pull the wire

expected behavior: cmd should exit w/ event and timestamp

Leave the wire open (Pull-up will pull the Pin permanently up

Exe: sudo gpiomon -r -n1 -Bpull-up <chip> <offset>

expected behavior: cmd should "hang" and wait for rising edge @ Pin

failure: cmd exits w/ false event and timestamp although there was no rising edge (Pin was permanently high)

all subsequent calls to gpiomon will fail w/ false event (behavior as "Level" Interrupt)

 

1. The issue is most likely related to initialization problems. Pins can be connected to various points internally in the SoC. UART, I2C, PIO...  as well to pull-up/down, Highend/lowend FETS, etc. To do this, an internal microcode needs to be executed in the chip. In many uControllers, the Pin becomes unstable during the execution of the uCode. I expect that upon each execution of the gpiomon cmd, the pin is newly initialized. The new 2nd & ff initializations could lead to a false rising edge flag in the chip register, which will then trigger a spurious interrupt, when enabled. I suggest to consider, writing the chip config registers only after reading them before and in case that the new config would be different, from what was read back, before.
2. Attaching the wire/button to a pin leads to line bouncing effects. The rising edge flag in the SoC may be re-triggered during the ISR execution of the 1st rising edge. The next execution of gpiomon, which will enable interrupts again, will then be trapped by the pending int flag. Enabling interrupts in the SoC PIO should always happen, after making sure that there is no pending int-flag, somewhere.

RGDS

hk

 

08.04.2022 в 12:07, Hans Kurscheidt сказал:

Nobody feeling responsible for this??

Positive answer - no one is responsible!

 

You provided little information so that I could repeat this case on my board. But let's try to figure out what's going on.

 

Connector diagram for OPI-zero-plus-h5:

 

its all about these:

On 3/29/2022 at 11:23 AM, Hans Kurscheidt said:

RESET, gpiomon -r -n1 -Bpull-up 1 6   => No event,  -> pull line up /down, => event (as expected),  gpiomon -r -n1 -Bpull-up 1 6 => false event

pull-up 1 6 => PA6/SIM_PWREN/PWM1/PA_EINT6

 

To check, take a general purpose\I/O contact: CON4-12 - PD11

And first it needs to be configured as an output.

I used sudo gpioset 1 107=1
and connected a voltmeter to the contact

 

if sudo gpioset --mode=exit  1 107=1
sudo gpioinfo 1 | grep 107                
       line 107:      unnamed       unused   input  active-high
if sudo gpioset --mode=wait  1 107=1

sudo gpioinfo 1 | grep 107                       
       line 107:      unnamed       unused  output  active-high
 

I do not know how to understand this.

I can only assume that the command line is designed for quick tests, and the main work needs to be done in a program written using this library.

 

If the pin is configured as an input and we set it to 1, then after a while it returns to 0.

If the pin is configured as an output and we have set 1 on it. This state remains.

 

4 hours ago, Hans Kurscheidt said:

Connect 1 Pin of your choice to GND using a patch wire

Exe: sudo gpiomon -r -n1 -Bpull-up <chip> <offset>  //  rising edge, pull-up, exit after 1 event

expected behavior: cmd should "hang" and wait for rising edge @ Pin

 

4 hours ago, Hans Kurscheidt said:

Exe: sudo gpiomon -r -n1 -Bpull-up <chip> <offset>

expected behavior: cmd should "hang" and wait for rising edge @ Pin

failure: cmd exits immediately w/ false event and timestamp although there was no rising edge (Pin was wired to GND)

I managed to reproduce the false triggering of the gpiomon command

After this open problem has ended up in "old bug tracker (read only)", I would like to bring this up here again. Could somebody please illuminate my ignorance, how this issue will be treated further?

 

https://forum.armbian.com/topic/20166-opi-zero-h5-gpiodmon-generates-spurious-interrupts-upon-invocation/

RGDS

hk

 

This problem will not be considered by the armbian maintainers.

I'll try to explain.
This problem relates to the work\development of the kernel gpio subsystem.
The kernel has a corresponding gpio driver for the Raspberry Board.

For boards using Allwinner processors, there is no native driver in the kernel yet.

 

Armbian members are not developers of kernel drivers.

 

My and your personal interest in the gpio topic and the fact that you and I are discussing it here is relevant only to us.

 

I will return to development only in late autumn. If my actions are successful. I'll let you know.
But again, this is only a personal initiative.

 

On 6/3/2022 at 8:11 PM, Hans Kurscheidt said:

After this open problem has ended up in "old bug tracker (read only)"

 

Topics were moved there just temporally as we decide to tag them and mass move to respective forums. It took several weeks and we had to hire people to help us doing that, otherwise that job would take months to complete.

 

This should help everyone to get some control over forums information complexity. It should make it easier and faster to find and group content. It helps you.

 

On 6/3/2022 at 8:11 PM, Hans Kurscheidt said:

how this issue will be treated further?

 

It won't be recorded or treated as we are already way over the budget. Public don't support or invest into this project enough while our private financing for random R&D has limits. Public support we receive - users donations - is only good enough to cover petty expenses project has, while it can't even cover basic staff expenses, any even smallest R&D task, needed to maintain this project without providing any end user support. I am sure you understand that.

vor 15 Stunden schrieb going:

This problem will not be considered by the armbian maintainers.

I'll try to explain.
This problem relates to the work\development of the kernel gpio subsystem.
The kernel has a corresponding gpio driver for the Raspberry Board.

For boards using Allwinner processors, there is no native driver in the kernel yet.

 

Armbian members are not developers of kernel drivers.

 

My and your personal interest in the gpio topic and the fact that you and I are discussing it here is relevant only to us.

 

I will return to development only in late autumn. If my actions are successful. I'll let you know.
But again, this is only a personal initiative.

Thank you very much. Its understood and appreciated! However I hope that the old sysfs i/f will stay in place until the issue will be solved.