App timer high current consumption

RE: App timer high current consumption

AmbystomaLabs — Wed, 10 Jan 2018 15:36:07 GMT

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.

RE: App timer high current consumption

cirlam — Wed, 10 Jan 2018 10:41:47 GMT

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.

RE: App timer high current consumption

AmbystomaLabs — Tue, 09 Jan 2018 16:12:12 GMT

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.