FreeRTOS Tickless Idle vs Tick Current Consumption

RE: FreeRTOS Tickless Idle vs Tick Current Consumption

WestCoastDaz — Wed, 17 Oct 2018 15:47:23 GMT

inghowe83 I forgot to mention that the ~110uA I quoted was on a design where most of the current was due to a lot of leakage through various protection circuits.

RE: FreeRTOS Tickless Idle vs Tick Current Consumption

inghowe83 — Wed, 17 Oct 2018 12:34:46 GMT

Thanks! It does help.

RE: FreeRTOS Tickless Idle vs Tick Current Consumption

mtsunstrum — Mon, 24 Sep 2018 06:02:57 GMT

From https://devzone.nordicsemi.com/f/nordic-q-a/35386/application-with-freertos---lowest-possible-current-in-idle it looks like one was able to get down to 9uA (when no advertising)

RE: FreeRTOS Tickless Idle vs Tick Current Consumption

WestCoastDaz — Wed, 01 Aug 2018 15:45:00 GMT

inghowe83 I don't have updated results in a form that I can share at the moment. This post is quite old and used very early versions of the S132 and SDK for the nRF52832. What I can tell is that for a recent project using S132 4.0.3 and SDK 13.0.0 which uses FreeRTOS in tickless idle we were getting an average quiescent current of ~110uA at 2.5V for normal operation with no advertising.

Does this help?

RE: FreeRTOS Tickless Idle vs Tick Current Consumption

inghowe83 — Wed, 01 Aug 2018 00:58:26 GMT

Hi Darren,

May I know what was the latest current consumption for your tickless project? What will be the current difference between system on Idle vs freeRTOS tickless?

RE: FreeRTOS Tickless Idle vs Tick Current Consumption

RK — Sat, 11 Jun 2016 07:51:08 GMT

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.

RE: FreeRTOS Tickless Idle vs Tick Current Consumption

WestCoastDaz — Sat, 11 Jun 2016 06:02:08 GMT

RK,

So I have some more to add to this thread thanks to your blog post on the Segger SystemView devzone.nordicsemi.com/.../ see above for a snapshot from a run with tickless idle enabled (the idle task hook is disabled). Note I re-purposed the FreeRTOS configPreSleepProcessing(x) and configPostSleepProcessing(x) to record the expected number of sleep ticks. It appears that FreeRTOS prepares to go to sleep, enters sleep and then immediately wakes up for some un-instrumented reason and then goes back to prepares to go back to sleep and succeeds.

Any thoughts would be greatly appreciated. Thanks, Darren

RE: FreeRTOS Tickless Idle vs Tick Current Consumption

WestCoastDaz — Sat, 11 Jun 2016 06:01:30 GMT

RE: FreeRTOS Tickless Idle vs Tick Current Consumption

RK — Wed, 08 Jun 2016 02:42:24 GMT

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.

RE: FreeRTOS Tickless Idle vs Tick Current Consumption

WestCoastDaz — Wed, 08 Jun 2016 00:05:54 GMT

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.

RE: FreeRTOS Tickless Idle vs Tick Current Consumption

RK — Tue, 07 Jun 2016 12:03:50 GMT

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.

RE: FreeRTOS Tickless Idle vs Tick Current Consumption

Anders Strand — Tue, 07 Jun 2016 10:38:09 GMT

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?

RE: FreeRTOS Tickless Idle vs Tick Current Consumption

RK — Sat, 04 Jun 2016 01:08:12 GMT

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

RE: FreeRTOS Tickless Idle vs Tick Current Consumption

RK — Sat, 04 Jun 2016 00:59:37 GMT

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

RE: FreeRTOS Tickless Idle vs Tick Current Consumption

WestCoastDaz — Fri, 03 Jun 2016 22:50:42 GMT

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()

RE: FreeRTOS Tickless Idle vs Tick Current Consumption

WestCoastDaz — Fri, 03 Jun 2016 22:47:15 GMT

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.

RE: FreeRTOS Tickless Idle vs Tick Current Consumption

RK — Fri, 03 Jun 2016 10:53:47 GMT

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.

RE: FreeRTOS Tickless Idle vs Tick Current Consumption

www.FreeRTOS.org — Fri, 03 Jun 2016 08:05:58 GMT

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.