lost Interrupts for Digital Pin and attached ISR function

[AchimErk]

Hi, I have a Push Button with pullup connected to digital in pin. I'm reading from digital Pin having attached an IRQ routing attachInterrupt(digitalPinToInterrupt(pin), IRQ_ForPin, CHANGE) In the Interrupt routing I read the value of the pin value = DigitalReal(pin)

My problem is, that sometimes the value read is not the value of the pin. So there was a PIN change, but no further call to the ISR routine. Thats why I call this a lost interrupt.

Looking at the IRQ handling shows, that IRQ routing is called before interrupt is cleared. So pin may change after I read and before IRQ is cleared. Thats seems to be the problem. I fixed by clearing IRQ after call attached function.

After doing this change, this issue is gone:

From WInterrupts.c: void EIC_Handler(void) { [...] { if ((EIC->INTFLAG.reg & ISRlist[i]) != 0) { // interted here by me // Clear the interrupt EIC->INTFLAG.reg = ISRlist[i];

 // Call the callback function
 ISRcallback[i]();

 // commented out here by me
 // Clear the interrupt
 // EIC->INTFLAG.reg = ISRlist[i];

} } }

I can not see any advantage of clearing IRQ after calling the attached function. So I assume, that is a bug.

What are your thoughts? Can this be fixed?

Thanks and best regards Achim

[tigoe]

I'm getting a related (I think) behavior. Theoretically, all the pins on the SAMD should be usable as interrupts, but it's not working that way. A few tests I did with a Nano 33 IoT, which should be repeatable:

1. Run this code:

int pin = 2;
volatile int state = LOW;

void setup() {
    pinMode(pin, INPUT_PULLUP);
    pinMode(LED_BUILTIN, OUTPUT);
    attachInterrupt(digitalPinToInterrupt(pin), blink, CHANGE);
}

void loop() {
    digitalWrite(LED_BUILTIN, state);
}

void blink() {
    state = !state;
}

2. Change pin number. It seems to work for pins 2, 3, 9, 10, 11, but that's it.
3. Run Paul Stoffregen's Encoder library using a rotary encoder and any two pins. Works on interrupts except for pins 5 and 6.

I haven't diagnosed why this is, but it is repeatable.

[FerGT50]

I think this is a bug.

Solved by following luni64's suggestion:

https://github.com/luni64/EncoderTool/issues/2#issuecomment-831365667

Sorry, don't know how to properly submit a PR yet!