This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Waking the nRF51 / 52 from SD_APP_EVT_WAIT

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?

Parents
  • 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

  • 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.

Reply
  • 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.

Children
No Data
Related