InterruptIn not working with EFM32 and tickless

[amq]

Description

• Type: Bug
• Priority: Major
• Related: Fix for Silicon Labs RTC #5854, RTX idle: sleep without locked deep sleep fix #5866, Why does default_idle_hook() lock deep sleep? #6199

---

Bug

Target
Tested on EFM32PG12

Toolchain:
GCC_ARM

Toolchain version:
6-2017-q2-update

mbed-cli version:
1.3.0

mbed-os sha:
caeaa49

Expected behavior

InterruptIn should wake the MCU from deep sleep.

Actual behavior

Tickless actually works quite well on EFM32. Even complex and time-sensitive communications are fine, with i2c, spi, uart. Even cellular. But the problem came from an unexpected thing: InterruptIn.

Steps to reproduce

InterruptIn interrupt(Pin);
motion.rise(callback(&isr));

isr() never gets called while the MCU is in deep sleep. As soon as it wakes and stays in a longer communication (e.g. cellular), it gets called without issues.

[amq]

Approach	Result
MBED_TICKLESS	InterruptIn not working, else OK
MBED_TICKLESS + Thread::attach_idle_hook(&sleep);	OK
Thread::attach_idle_hook(&sleep);	Stuck on first Thread::wait()

[0xc0170]

@ARMmbed/team-silabs Please review

[stevew817]

@amq Do you have a full reproducer you can point me to?

[amq]

@stevew817

mbed_app.json

{
    "target_overrides": {
        "EFM32PG12_STK3402": {
            "target.macros_add": [
                "MBED_TICKLESS"
            ],
            "events.use-lowpower-timer-ticker": true
        }
    }
}

main.cpp

#include "mbed.h"

InterruptIn interrupt(BUTTON1);
DigitalOut led(LED1);

void isr() {
    led = !led; // never reached unless you uncomment Thread::attach_idle_hook()
}

int main() {
    interrupt.rise(callback(&isr));

    // Thread::attach_idle_hook(&sleep);
}

[amq]

@stevew817 does it reproduce for you?

[stevew817]

Sorry, I've been out sick the last couple of days. Will try to reproduce now.

[stevew817]

@amq I'm unable to reproduce using your reproducer. The button interrupt fires as it should.

[stevew817]

See energy trace:

Energy usage is as expected, with ~4uA in deepsleep with LED off, and ~0.5mA in deepsleep with LED on. You can see the current spikes when it wakes up to handle the button press.

Why there is a spike every 40ms, I'm not sure.

[stevew817]

@amq If you're seeing interrupts fail as part of a bigger circuit, it would be helpful to know for which pins you've registered interrupt handlers. There is a limitation on Silicon Labs parts as to which pins can be used simultaneously for interrupts on mbed.
short version: you can't register handlers for pins on different ports that have the same pin number. I.e. GPIO IRQ's on PA0 and PB1 is fine, but not PA0 and PB0.

[stevew817]

For reference, I did a "mbed new ." and then just created the two files you pasted in this ticket. Works both on regular and debug build, and with or without the attach_idle_hook call.
This is on mbed-os 91e6db1. Reverting to caeaa49 didn't cause any failures either.

[amq]

@stevew817 thank you for looking into this so closely! I'm enabling these pins as interrupts: PC8, PC9, PI3. The strangest thing is that when the MCU exits EM2, the interrupts are firing, so it's not like the devices which should be creating them couldn't be configured because of some communication issue.

[amq]

Maybe relevant, here is my device_peripherals.h:

/* us ticker */
#define US_TICKER_TIMER         TIMER0
#define US_TICKER_TIMER_CLOCK   cmuClock_TIMER0
#define US_TICKER_TIMER_IRQ     TIMER0_IRQn

/* PWM */
#define PWM_TIMER        TIMER1
#define PWM_TIMER_CLOCK  cmuClock_TIMER1
#define PWM_ROUTE        TIMER_ROUTE_LOCATION_LOC1

/* Crystal calibration */
#if !defined(CMU_HFXOINIT_STK_DEFAULT)
#define CMU_HFXOINIT_STK_DEFAULT CMU_HFXOINIT_DEFAULT
#endif

#define EMU_NO_DCDC