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

App timer high current consumption

I have a need for an interrupt to go off at a 4khz rate. For this, I am using a repeated App Timer (running off the 32k crystal).

Prior to adding this extra timer, we used to have a power consumption of about 60ua. If I enable the timer to run at 4khz (and do nothing at all within the interrupt handler), power consumption goes up significantly - ~1.3ma. Is there any obvious reason why this happens?

I am setting up the app timers in the same way as the other 5 timers used in the project (which work with the low 60ua current consumption). With a couple of mods (to toggle a pin within the interrupt routine), we have checked on an oscilloscope, and the interrupt appears to be serviced very quickly.

I am currently using Softdevice v3.0.0, NRF52832, SDK version 12.2.

  • The question that comes to mind is, "what was the period of your other app timers?" 4kHz is pretty fast for an interrupt rate. Every time the interrupt happens the processor has a lot of work to do even if nothing is in the handler. Also, since this pulls it out of power manage main runs until it starts power manage again. So you could have a lot of code running in main.

    You should be careful trying to have so many ISR's with the SD running. Unless you use timeslotting there is no coordination between the SD and your code so your ISR's will occasionally be delayed and queued.

    If your 4kHz is just toggling gpio or causing a comms task to run that has DMA then instead use ppi/gpiote to trigger the task and keep it out of code.

  • The other app timers are comparatively slow:

    • 1 triggers every second
    • another every 30 seconds
    • another the moment before the RTC overflows
    • then there are 2 single shot timers which are only used during the start of the program.

    My main loop consists of a while loop which puts the device back into power manage unless I have set a flag which then requires it to step out of the while loop and do some additional work (this typically happens every 0.3 seconds currently). There will be some calculations occurring within the timer interrupt routine, so unfortunately PPI isn't a viable option.

    We have checked the data sheet and the wake up time from idle advertised in the data sheet suggests this should be doable at low power - however I suspect the data sheet is for the raw device, not when the soft device is running as well.

  • What I had implied in my comment was that you cannot do what you are proposing.

    The SD always has highest priority in the system. So just advertising beacons alone keep you locked out of the processor for about 700usec a little before and during beacon intervals. If you are actually in a connection and transferring data then this latency just gets worse.

    This latency alone is nearly 3 cycles of your 4kHz clock which guarantees 3 interrupts will get queued and serviced late periodically. Finally when you consider that just servicing an empty handler requires a few opcodes and putting the processor back into power manage is probably a few dozen more you will realize you are asking the processor to do quite a bit every millisecond.

    The only way to implement kHz timing of anything is ppi/gpiote. Just search the devzone on how to do this. It is a common question.

Related