Interrupts don't fire on CHANGE

[fathat]

Hi there,

I'm running into an issue where code works with attachInterrupt() for RISING and FALLING values. (Haven't tried HIGH or LOW but I assume those are fine). However, CHANGE never fires, no matter what pin is used. Seen on both the artemis nano and artemis uno.

In the mean time while this is being fixed, can you link me to any examples of how to do this with the ambiq sdk so I can work around the issue? I spent about an hour looking for something but it seems like the mechanism works very differently there.

[fathat]

Hi there,

I'm running into an issue where code works with attachInterrupt() for RISING and FALLING values. (Haven't tried HIGH or LOW but I assume those are fine). However, CHANGE never fires, no matter what pin is used. Seen on both the artemis nano and artemis uno.

In the mean time while this is being fixed, can you link me to any examples of how to do this with the ambiq sdk so I can work around the issue? I spent about an hour looking for something but it seems like the mechanism works very differently there.

A bit of additional info: HIGH and LOW do work. I can also work around this by just using two interrupt pins connected to one interrupt source (one for high and one for low). Would definitely prefer to be able to use the CHANGE function though.

[adamgarbo]

I wonder if this is related to the RTC and WDT interrupt service routine (ISR) issue I'm currently troubleshooting. For some reason, it doesn't appear that interrupts are triggering properly.

[fathat]

I wonder if this is related to the RTC and WDT interrupt service routine (ISR) issue I'm currently troubleshooting. For some reason, it doesn't appear that interrupts are triggering properly.

I'd be interested in hearing about those -- I'm also seeing an issue with a timing dependent I2C device (the pololu opt3101 if you're curious) returning incorrect values; not sure if it's a bug in their library or the artemis though which is why I haven't filed anything.

[paulvha]

Root cause :
The problem is in arduino/mbed-bridge/core-implement/CommonInterrupt.cpp routine : InterruptInParam::_irq_handler().
The interrupt event that is passed back is only checked on IRQ_RISE (1) or IRQ_FALL (2), however in case of CHANGE, both are set, so the event value is 3. MBED does not have a variable BOTH or CHANGE. It knows IRQ_NONE, IRA_RISE and IRQ_FALL (mbed-os/hal.gpio_irq_apil.h)

Solution :
The way to handle, change in the _irq_handler change :

        case IRQ_RISE:
            if (handler->_rise) {
                handler->_rise(handler->_rise_param);
            }
            break;

to

        case IRQ_RISE:
        case (IRQ_FALL | IRQ_RISE):      //<<<<<<<<<<<<<<<<<< add this to get both
            if (handler->_rise) {
                handler->_rise(handler->_rise_param);
            }
            break;

As this file is NOT in the MBED archive, you can change it now, recompile the sketch and it works.

Regards,
Paul

[fathat]

Root cause :
The problem is in arduino/mbed-bridge/core-implement/CommonInterrupt.cpp routine : InterruptInParam::_irq_handler().
The interrupt event that is passed back is only checked on IRQ_RISE (1) or IRQ_FALL (2), however in case of CHANGE, both are set, so the event value is 3. MBED does have a variable BOTH or CHANGE. It knows IRQ_NONE, IRA_RISE and IRQ_FALL (mbed-os/hal.gpio_irq_apil.h)

Solution :
The way to handle, change in the _irq_handler change :

        case IRQ_RISE:
            if (handler->_rise) {
                handler->_rise(handler->_rise_param);
            }
            break;

to

        case IRQ_RISE:
        case (IRQ_FALL | IRQ_RISE):      //<<<<<<<<<<<<<<<<<< add this to get both
            if (handler->_rise) {
                handler->_rise(handler->_rise_param);
            }
            break;

As this file is NOT in the MBED archive, you can change it now, recompile the sketch and it works.

Regards,
Paul

Thanks! I'll try that out

[paulvha]

Working on SoftwareSerial and trying to use MBED-OS, I run into the exact same issue. MBED-OS (drivers/soruce/InteruptIn.cpp) is also only checking on falling or rising. It would mean a change in MBED-OS and not sure they want to do that. Another solution is to make a change in the Ambiq target :
path : mbed-os/targets/TARGET_Ambiq_Micro/TARGET_Apollo3/device
file : gpio_irq_api.c
Routine : gpio_irq_set

Around line 131 add to :

        case (IRQ_RISE | IRQ_FALL):
            ap3_int_dir = AM_HAL_GPIO_PIN_INTDIR_BOTH;

to

        case (IRQ_RISE | IRQ_FALL):
            ap3_int_dir = AM_HAL_GPIO_PIN_INTDIR_BOTH;
            obj->control->events &= (~IRQ_FALL);        // else checks will fail with MBED and we assume it will always call RISE

[Wenn0101]

Fixed in v2.1.0.
As paul mentioned the mbed core does not like CHANGE as an option. Changed the driver to the artemis to report up to mbed that a RISE has happened even when CHANGE is enabled, similar to the suggestion by @paulvha. This allows us to keep CHANGE as an option without upsetting the mbed core.