FreeRTOS Tickless Idle vs Tick Current Consumption

[WestCoastDaz]

We have been comparing the current consumption of the nRF52 running FreeRTOS Tickless Idle versus a constant tick and using the idle task to sleep and the results are interesting, see below.

June 7th Edit: SDK 11, SoftDevice S132 2.0.0.0, Silicon is QFAABB (Rev C)

Tickless Idle:

• Average current is 390uA

Tick with Idle Task:

• Average current is 303uA

Both runs were identical with the floating point interrupt handler implemented as in this post devzone.nordicsemi.com/.../, same number tasks/execution profile, same tick rate, advertising off. The only difference is tick mode uses the idle task hook to put the processor to sleep.

Note the follow images were captured using our own Labview tool sampling at 8kHz. Ignore the bottom trace

Tickless Idle

Tick with Idle Task

[www.FreeRTOS.org]

From a first glance, the two plots do not appear to be showing the same execution pattern, assuming the current spikes are where interrupts are being executed. The bottom plot shows a regular periodic current spike, which I am assuming is the tick interrupt. The top plot is showing current spikes with no determinable pattern, so what is being processed during the current spikes? If these spikes are interrupts other than the tick interrupt being processed, then why do those interrupts not show on the bottom plot too?

How often are the floating point interrupts being generated? If it is at a rate greater than the setting of configEXPECTED_IDLE_TIME_BEFORE_SLEEP then there is no point in using tickless idling - but that would not explain the lack of these current spikes in the bottom plot.

Are you sure the tickless idle period is actually being calculated correctly, and you not seeing spikes when the system is coming out of tickless mode at an erroneous time?

When you use tickless idle, with a clock other than the SysTick, you have the opportunity to enter a much deeper sleep that if you either use the SysTick or use the idle task as per the lower plot. That is because you have the opportunity to turn more clocks off. Are you making use of a deep sleep mode in the tickless idle case? Note again though, that entering a deep deep sleep mode takes time to enter and exit, so the benefits are obtained when you are sleeping for long periods, not when continuously processing other interrupts that bring you out of sleep mode.

[RK]

I also can't figure out what on earth would produce those results.

What's running on the chip, do you have the softdevice loaded and active, is it doing anything at all? The tickless mode should be showing less than the other one, if it has nothing scheduled then it should put itself to sleep for seconds or minutes or basically forever.

Are you sure you've got this test right? Because it really makes no sense at all.

[WestCoastDaz]

We are instrumenting the floating point interrupt to see how often it's triggering but I can tell you that we don't have a lot of floating point operations. We are not using Systick since it's clocked with the processor core in this part, we are using one of the RTC clocked from 32.768kHz.

I don't know if the tickless idle period is actually being calculated correctly what's the best way to this?

From a test perspective the the system is configured in the exact same way.

[WestCoastDaz]

RK,

Yes, we are sure we have the test right the results can be easily duplicated. Yes, the softdevice is loaded and active but advertising is disabled.

As I said above the only difference is tick mode is using the idle task and is calling sd_app_evt_wait() where as tickless idle has the idle task disabled and is using Nordic's implementation of vPortSuppressTicksAndSleep()

[RK]

I can't think up a scenario which would give those results. OK so the SD is on but not even advertising, which means it generates no interrupts, it's really doing nothing at all. What code do you have running, just a few tasks which run on a timed basis or are there async bits to it, like external interrupts, SPI/TWI/UART data transfers etc? If it's just tasks running on timers, there's nothing to cause the chip to wake from sleep apart from the RTC tick, which runs (in the nordic port) at the RTOS tick rate.

I wondered if the tick idle was being entered with interrupts turned off (BASEPRI set) but if that were the case, the RTC tick wouldn't wake you either, so that can't be it.

I assume in the idle handler you're just calling sd_app_event_wait(). The reason it makes no sense is because the Nordic RTOS port also just calls sd_app_event_wait() in the tickless function ...