This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

FreeRTOS sleep optimization from main task

Hello -

We are using the nRF52840-DK with the 15.3.0 SDK on FreeRTOS. Our application is configured for tickless idle and based on the ble_app_hrs_freertos example. I have confirmed that sd_app_event_wait() is being called from the vPortSuppressTicksAndSleep() function.

I have read a number of posts here where developers in the past have edited the port_cmsys_systick.c file to workaround various sleep and power management issues. I wanted to confirm this is no longer necessary with SDK 15.3.0. In other words, all that should be required by a "well behaved" FreeRTOS application is to enable deep sleep mode (System ON sleep) by setting the associated bit in the system control block:

    // Activate deep sleep mode.
    SCB->SCR |= SCB_SCR_SLEEPDEEP_Msk;



Assuming that is the case, I am wondering if any additional SoftDevice sleep management calls are needed by our FreeRTOS tasks. In particular, we create a "main" task that loops, calling xQueueReceive(), waiting for entries in a message queue:

if (xQueueReceive(msgQueue, &msg, maxDelayMS)) {

   // process received message
}

The maxDelayMS value is pre-calculated based on the application configuration. If there are no messages in the queue, the FreeRTOS task blocks for maxDelayMS. Does this task block interfere with the SoftDevice sleep mode? If so, I'd like to know how to optimize this portion of the code to ensure that System ON sleep isn't interrupted if there are no messages in the queue. Also in the loop should we also be calling  sd_power_mode_set() after calling xQueueReceive()?

Regards,

Brian



Parents
  • Hi Brian,

    Your understanding is correct. There should not be any other sleep management in the tickless idle apart from the one in vPortSuppressTicksAndSleep. The call to xQueueReceive will block the calling task if there are no messages in the queue and hence will call the scheduler. Which means that this task is yielding correctly in this scenario and if there are no other tasks to run apart from the idle task, then vPortSuppressTicksAndSleep will be called and the system will go to sleep mode. You do not need to worry about the softdevice wakeup routines as sd_app_evt_wait call will only wake the application if it is application specific event.

Reply
  • Hi Brian,

    Your understanding is correct. There should not be any other sleep management in the tickless idle apart from the one in vPortSuppressTicksAndSleep. The call to xQueueReceive will block the calling task if there are no messages in the queue and hence will call the scheduler. Which means that this task is yielding correctly in this scenario and if there are no other tasks to run apart from the idle task, then vPortSuppressTicksAndSleep will be called and the system will go to sleep mode. You do not need to worry about the softdevice wakeup routines as sd_app_evt_wait call will only wake the application if it is application specific event.

Children
Related