Interrupt is triggering once after enabling

[lefebvresam]

When I use an interrupt:

m_irq.mode(PullUp);
eventThread.start(callback(&queue, &EventQueue::dispatch_forever));
m_irq.fall(queue.event(callback(this, &RA8875::TouchPanelISR)));
m_irq.disable_irq();   // ensure it is disabled until the init()

After a while I enable it:

m_irq.enable_irq();

And it is alway triggered once before the real falling edges occur.

[lefebvresam]

I already tried this in gpio_irq_api.c for TARGET_STM32U5:

    /* Restore previous edge interrupt configuration if applicable */
    if (obj->event & IRQ_RISE) {
        LL_EXTI_EnableRisingTrig_0_31(1 << STM_PIN(obj->pin));
        LL_EXTI_ClearRisingFlag_0_31(1 << STM_PIN(obj->pin)); // added
    }
    if (obj->event & IRQ_FALL) {
        LL_EXTI_EnableFallingTrig_0_31(1 << STM_PIN(obj->pin));
        LL_EXTI_ClearFallingFlag_0_31(1 << STM_PIN(obj->pin)); // added
    }

But this is not solving the issue.

[lefebvresam]

After some investigation I find out that after this call:

void InterruptIn::enable_irq()
{
    core_util_critical_section_enter();
    gpio_irq_enable(&gpio_irq);
    core_util_critical_section_exit();  // < this one
}

in InterruptIn.cpp, the interrupt is fired three times. I did that test by inserting 5s delays before and after.

[lefebvresam]

I found it by using this method:

1/ I created a test project with interrupt in CubeIDE and saw that the interrupt was not triggered before enabling and before the first edges.

2/ I created a test project in Mbed-ce and saw the same.

3/ I put pulses on an output pin to check the exact timing between the events.

   // PULSE X

    DigitalOut testout(OUT_4);
    testout.write(1);
    wait_us(1000);
    testout.write(0);

And I saw it is my touch controller chip that is producing falling edges.

Yellow = reset line touch controller chip Red = interrupt line touch controller chip Blue = test glitches Green = Serial data (last 3 produced by interrupt ISR)

• Block between the first two glitches: reset precedure of the GT911 TC chip, where I drive the IRQ to setup a device address.

• Block between the second two glitches: setup of the GT911 and enabling interrupt. Depending on the timing the touch controller sends 3 or more interrupts. I think you need to readout at least 3 interrupts before the chip stops firing interrupts.

And obviously you have the same behavior at startup.

So it has nothing to do with the deeper implementation of interrupts. I broke my head on all cmsis calls and don't understand it that much. Seems to be much different than the Cube implementation.

I think the solution here is to wait after the first 'touch release' event before interpreting the other events. It means waiting for the interrupt trigger is not coming for 20ms afther this event.

[multiplemonomials]

Nice debugging, glad you figured it out! Good to close this then?