GPIOTE interrupt not being serviced

RE: GPIOTE interrupt not being serviced

Susheel Nuguru — Wed, 07 Sep 2016 11:46:57 GMT

OK, so two GPIOTE events were happening very close to each other. That makes sense, thanks for coming back and answering.

RE: GPIOTE interrupt not being serviced

bvuong87 — Tue, 30 Aug 2016 21:36:52 GMT

Hi Aryan, sorry for the delay.. distracted by a few higher priority tasks.

GPIOTE is LOW priority, which schedules the interrupt_event_func using app_sched_event_put:

if(flag){ do some processing here; flag = 0;}

Scheduled interrupt_event_func is "processed" in main loop using app_sched_execute()

RE: GPIOTE interrupt not being serviced

Susheel Nuguru — Tue, 16 Aug 2016 06:27:29 GMT

Sorry, i got little confused now. where are you checking for the flag being set? i mean is it inside another ISR? If your GPIOTE ISR is at higher priority than the one checking for flag, then interrupt occuring while in the ISR should be no problem, because then the context that checks for the flag will not get the chance to run at all. Maybe i did not understand correctly the overall architecture of what you are achieving to do. But could you please clarify priorities of GPIOTE ISR and the context where you are checking for the flag

RE: GPIOTE interrupt not being serviced

bvuong87 — Mon, 15 Aug 2016 19:14:50 GMT

Hi @aryan,

Thanks for working through this with me. I think I've figured out what the issue was... In my GPIOTE irq handler, there is a flag set that tells the scheduled function what sort of processing is needed.. i.e:

void gpiote_event_handler(nrf_drv_gpiote_pin_t pin, nrf_gpiote_polarity_t action)
{
    if (pin == GET_GPIO_PIN(24) && action == NRF_GPIOTE_POLARITY_LOTOHI)
    {
        flag = 1;
        app_sched_event_put(NULL, 0, interrupt_event_func);
       
    }
}

and the interrupt event func:

if(flag){ do some processing here; flag = 0;}

I think what was likely happening is another GPIOTE event was occurring before the interrupt finished processing, so the second event's flag was also cleared and never serviced

RE: GPIOTE interrupt not being serviced

Susheel Nuguru — Thu, 11 Aug 2016 06:27:04 GMT

well you said that you are putting all the processing into the scheduler. Which interrupt context does the scheduler run (where do you call app_sched_event_get?) Well the third line says that the interrupt has happened so this means that nRF chip will not loose it (unless last two interrupts happened while softdevice locked the CPU in which case the former one will not be serviced)

I would like to see some code, if you cannot share it, then please open a support case and you can share anything there as we would then be bound by NDA.

RE: GPIOTE interrupt not being serviced

bvuong87 — Wed, 10 Aug 2016 17:17:27 GMT

@aryan thanks for the quick response. The reason we're including PAN #73 is we've been developing our project mostly on dev kits PCA10040 v 0.9.0.. Top Mark QFAABA.

I've tried changing the GPIOTE priority to APP_IRQ_PRIORITY_HIGH just now, and the behavior is identical. After the 8th interrupt, no additional I2C activity is observed on that line, but the other sensor is still responsive.

The way our project is setup, is that the GPIOTE interrupt calls the interrupt event function, which adds most of the actual processing to the scheduler using app_sched_event_put().

Any additional thoughts or reasons you can think of as to why this "scheduled" interrupt isn't being tended to?

Thanks!

RE: GPIOTE interrupt not being serviced

Susheel Nuguru — Wed, 10 Aug 2016 08:11:33 GMT

Hi,

If you are using revision Rev 1 (QFAA-B00, QFAB-B00, CIAA-B00, CHAA-B00) or revision Engineering C (QFAA-BB0, CHAA-BA0, CIAA-BA0) chips then you do not need to implement PAN73 workaround. It only applies to older Engineering B (QFAA-BA0, CHAA-AA0) and Engineering A (QFAA-AA0, QFAA-AC0, CGAA-AA0) revisions.

The behavior with peripheral interrupt along with softdevice activity has been discussed extensively in this forum. In short, the softdevice has highest priority over everything and depending on your BLE activity, softdevice will use CPU time that delays your peripheral interrupt being services until softdevice releases the CPU. You can use APP_IRQ_PRIORITY_HIGH for your interrupt so that this is the next thing serviced after softdevice code. This will improve the frequency of peripheral interrupt servicing but still wont be able to catch up high frequency interrupt.