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

FreeRTOS Tickless Idle vs Tick Current Consumption

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

image description

Tick with Idle Task image description

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

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

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

Children
No Data
Related