Waking the nRF51 / 52 from SD_APP_EVT_WAIT

[Caleb C]

We have an ISR parsing incoming serial data from the UART. When a valid packet arrives, I'd like to be able to wake the core from whatever low-power state is entered when the sd_app_evt_wait() function is called within the main loop.

Is there an SOC event or app event that can be manually triggered through the API to wake the core and start processing? Can custom events be added that wake the core and cause custom handlers to be executed?

[AmbystomaLabs]

You don't have to do anything. The interrupt request will automatically wake the processor so that your interrupt handler can run. And, regarding can custom events be added... Yes, essentially anything that generates an interrupt (timers, gpio, comms, etc.) will wake the processor so that they will be serviced. The only caveat is that your interrupts will wait to be serviced until the SD is done handling TX or RX activity.

See here: developer.nordicsemi.com/.../a01075.html

[Caleb C]

Of course the ISR runs. But when it exits, does execution begin immediately after sd_app_evt_wait(), or does the processor go back to sleep and wait for an app or SOC event to continue operation?

Regarding events, I found the app_scheduler in the SDK, and it should do nicely. We just want to make sure that the main loop continues operation right away after the ISR returns, even if the core was sleeping due to a call to sd_app_evt_wait().

[AmbystomaLabs]

Both according to the Nordic spec and according to my empirical evidence, execution continues at the command after the evt_wait when it returns from servicing the request. It is for this reason it is normally put in a while or for loop at the end of main so that evt_wait is called after each wake up. If you have general housekeeping to do in main then you can put code in the same loop with the evt_wait and it will execute each time the processor wakes up.

However, if you have something more time sensitive to do in main, then it is my understanding the app_scheduler is the way to go. However, I have never had need for the scheduler since all the important stuff in my code runs in handlers.

[Caleb C]

Awesome. My own tests also confirm that execution continues. In retrospect, it would be quite odd if the processor did not resume execution after waking to service a HW interrupt.

The app_scheduler just queues up a callback function and executes in the main loop on a call to app_sched_execute(). We put that right after the call to sd_app_evt_wait() so that when the ISR returns, the more time-consuming code starts executing right away in the main context instead of in an ISR. Pretty handy.

[AmbystomaLabs]

I'm glad it worked out as expected. If you could, please close out the question as "answer accepted". I'm trying to improve my points on the blog. Thanks in advance.