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

FreeRTOS power consumption spikes when in System ON sleep mode

Hello -

We are developing on the nRF52840-DK, using SDK 15.3.0 and FreeRTOS with tickless idle. The SoftDevice is disabled. Using the PPK v2.3.1 when our app is in System ON sleep mode, we are seeing power consumption spikes at regular ~1s intervals:

During this period our app is waiting on messages from a FreeRTOS message queue. At this time there are no other pending tasks:

xQueueReceive(msgQueue, &msg, maxDelayMS);

After maxDelayMS we enter System OFF sleep mode and the current drops for the duration:

NRF_POWER->SYSTEMOFF = 1;

I toggle an onboard LED in the vPortSuppressTicksAndSleep() function before and after System ON sleep. The LED toggles only once after the specified delay, which leads me to believe that the sleep logic is working as expected. After some experimentation, I found that the RTC wakeup interrupt configuration leads to the spikes. If I comment out this code, the spikes no longer occur, but of course the app never exits System ON sleep:

/* Configure CTC interrupt */
nrf_rtc_cc_set(portNRF_RTC_REG, 0, wakeupTime);
nrf_rtc_event_clear(portNRF_RTC_REG, NRF_RTC_EVENT_COMPARE_0);
nrf_rtc_int_enable(portNRF_RTC_REG, NRF_RTC_INT_COMPARE0_MASK);

Is there anything we can do in our app or FreeRTOS configuration to eliminate these spikes?

Regards,

Brian

  • Hi.

    Nordic technical support staff is reduced due to the christmas holiday in Norway.
    We will be back to full staffing at 6th of January, and might not be able to provide you with an answer before that.

    Best regards,
    Nordic technical support

  • Hello -

    Just checking back after the holiday break. Still looking for a solution to eliminate the power consumption spikes.

    Regards,

    Brian

  • Hi.

    Apologize for the delay. 

    I'm not too familiar with FreeRTOS, and our engineer working with FreeRTOS is currently out of office.
    He'll be back in office tomorrow (14/1), and I'll have him take a look at your issue then. 

    Br, 
    Joakim

  • Your system seems to be sleeping most of the time and hence you managed to pull the power consumption low most of the time.

    The configEXPECTED_IDLE_TIME_BEFORE_SLEEP in the FreeRTOSConfig.h file decides the expected sleep time and after which the RTOS will wakeup to see if everything is ok and do the book keeping. You can increase this to a suitable value for you app and this should move the spikes farther apart if you increase the value.

  • Hello -

    I apologize for the very late follow-up here. We've since brought up our custom nRF52840 board and we are still seeing regular power consumption spikes at ~1s intervals when running under FreeRTOS, with tickless idle enabled, and using the vPortSuppressTicksAndSleep() function provided in the nRF52 SDK v17.0.

    We enter System ON sleep mode by waiting forever on a FreeRTOS task queue. Using the PPK, this is what we see when that happens:

    My understanding is that the spikes are related to the RTC wakeup configuration I described above.

    Changing the value of configEXPECTED_IDLE_TIME_BEFORE_SLEEP doesn't seem to help. As a test I bumped that value up to 2000 and the resulting power draw was much higher and constant.

    I did some experiments to try and isolate the problem. One of those experiments disables tickless idle and instead calls __WFE() from our application idle hook function. Here is the idle hook implementation:

    void vApplicationIdleHook( void )
    {
    #ifdef SOFTDEVICE_PRESENT
    	if (nrf_sdh_is_enabled())
    	{
    		uint32_t err_code = sd_app_evt_wait();
    		APP_ERROR_CHECK(err_code);
    	}
    	else
    #endif
    	{
    		/* No SD -  we would just block interrupts globally.
    		* BASEPRI cannot be used for that because it would prevent WFE from wake up.
    		*/
    		do{
    			__WFE();
    		} while (0 == (NVIC->ISPR[0] | NVIC->ISPR[1]));
    	}
    #endif
    }
    

    When we run this configuration, without tickless idle, the power spikes are essentially eliminated, but the average current consumption is much higher:

    Based on this experiment I am wondering if something in the vPortSuppressTicksAndSleep() function reduces current consumption. Ideally we are looking for a solution that eliminates the spikes but also reduces power consumption down to what we've measured when tickless idle is enabled.

    Thank you again for your helpful feedback. Looking forward to finding a solution.

    Regards,

    Brian

Related