• State Verified Answer
  • Locked Locked
  • Replies 3 replies
  • Subscribers 67 subscribers
  • Views 4467 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 102885
Options
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

app_sched_execute followed by sd_app_evt_wait

Louis

Hello,

I am working on a project based on the nRF51822 with the softdevice S110.

I am trying to develop an application using the main loop provided in an example application:

// Enter main loop
for (;;)
{
    app_sched_execute();
    <<-- interrupt raised here that calls app_sched_event_put
    sd_app_evt_wait();
}

I am puzzled by this code for the idle loop, I do not understand how the system handles a situation where an interrupt is raised between the execution of app_shed_execute and sd_app_evt_wait. If the interrupt invokes a app_sched_event_put, then the system will still go to (deep) sleep mode and will not execute the event handler until the next loop which could come much later. Am I missing something in the architecture?

Thanks Louis

  • 0

    Did you read this?

    /**@brief Waits for an application event.
 * 
 * An application event is either an application interrupt or a pended interrupt when the
 * interrupt is disabled. When the interrupt is enabled it will be taken immediately since
 * this function will wait in thread mode, then the execution will return in the application's
 * main thread. When an interrupt is disabled and gets pended it will return to the application's 
 * thread main. The application must ensure that the pended flag is cleared using 
 * ::sd_nvic_ClearPendingIRQ in order to sleep using this function. This is only necessary for
 * disabled interrupts, as the interrupt handler will clear the pending flag automatically for
 * enabled interrupts.
 *
 * In order to wake up from disabled interrupts, the SEVONPEND flag has to be set in the Cortex-M0
 * System Control Register (SCR). @sa CMSIS_SCB
 *
 * @note If an application interrupt has happened since the last time sd_app_evt_wait was
 *       called this function will return immediately and not go to sleep. This is to avoid race
 *       conditions that can occur when a flag is updated in the interrupt handler and processed
 *       in the main loop.
 *
 * @post An application interrupt has happened or a interrupt pending flag is set.
 *
 * @retval ::NRF_SUCCESS
 */
SVCALL(SD_APP_EVT_WAIT, uint32_t, sd_app_evt_wait(void));
  • 0

    Hello Nikita,

    Thanks and sorry, I had missed the note.

    If I understand correctly the note, it means that this main loop code is safe from race conditions: the system monitored interrupt handlers that were invoked outside of the wfe background wait and it will not wait if this was the case. Is my understanding correct?

    Thanks

    Louis

Related