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 hate that comments are limited) ... and the tickless function is called from the tick idle, just with the tick turned off and a compare interrupt turned on for a future time. So what you're doing sleeping in the idle handler is a superset of what tickless idle is doing, assuming you're even getting into tickless idle mode.

The bottom trace, are those spikes at your RTC tick frequency, it's tempting to assume they are, but perhaps they are only every 10 or 20 ticks. How often are you doing work, every tick? Less than 2-3 ticks of idle, you're not actually getting into sleep mode.

I've just spent bits of this week instrumenting things with SystemViewer, not only Nordic's FreeRTOS port but my own and also the softdevice itself. Would be interesting to apply that analysis, although having the debugger attached may mess up the results.

[Anders Strand]

When doing tickless idle, the port sets up a wakeup timer to wake up in time for the next rtos event. In your case, you are just going to sleep and "hope" that something wakes you up at some point. It could just be that the rtos "oversleeps" because there is no mechanism to wake it up in time. So the question is: What is waking up the CPU after sleeping in idle task?

[RK]

This is why I wanted to know what code is running, is it just timed code, at which point it will only task switch at a tick and I'd expect the bottom trace, or are there async events at which point I'd expect something like the top trace (assuming the async events call the yield function properly).

The only case in the middle is where it's timed code but the expected timeout is always one tick, so tickless mode never actually goes tickless and runs around the idle loop. I suppose running tickless and also putting sd_app_evt_wait() in the idle loop might be an interesting test, if it then looks like the bottom trace that would indicate that tickless mode isn't ever really being entered.

But yes knowing whether the code is just timer based or there's an async part to it would be rather helpful.

[WestCoastDaz]

RK, Anders,

Thanks for your thoughts.

In these tests the system is running using timed tasks the only peripherals running is the ADC and RTC1 for FreeRTOS. The debugger is disconnected and the UART is disabled. This is the case for both above traces. The spikes that RK asked about are at the ADC task frequency of 160ms and the . The ADC is configured for scan mode but has NRF_52_PAN28 defined. These tests are being run on QFAABB or Rev C silicon.

[RK]

still makes no sense. And you missed a bit "at the ADC task frequency of 160ms and the .. " and the what?

if all you've done is put sd_app_evt_wait() into the IDLE function then as long as you are actually getting into tickless idle mode (ie a long wait) the two tests are doing almost basically the same thing, because in the middle of the tickless loop in the port is just sd_app_evt_wait(). So the IRQ fires, you go around the scheduler loop once and back into tickless mode, unless an event is scheduled within a tick or two at which point it busy idles.

At this point I suggest you hook RTT up to both setups and log a minimal set of milestones along with the value of the cycle counter to work out when you are getting interrupted, when you enter the idle loop and when you start and end tickless mode and when you drop out of sd_app_evt_wait() in the idle loop.