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

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

[RK]

I don't think that's a problem, there's no guarantee that sd_app_evt_wait(), which is what's in the middle of the tickless idle loop, will actually sleep the chip. Much like WFE, you may have to call it twice in succession to start with for it to actually wait. If that's all that's happening, ie at the start of every tickless idle period you're going into tickless idle twice, I think that's fine, as long as it's only once every time, ie the second entry actually waits.

Probably if you instrumented the idle tick sd_app_evt_wait() you'd see something similar, two calls before it waits.

That doesn't explain the trace at the top still which has spikes all over the place.