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.

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

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

Children
No Data
Related