nRF52 idle current in timeslot

RE: nRF52 idle current in timeslot

Thiemo van Engelen — Fri, 24 Mar 2017 15:31:36 GMT

OK... Some more observations:

Changing to constant latency mode in the beginning of the timeslot does not increase the current consumption in the timeslot, but does increase the current consumption outside of the timeslot such that they are almost the same level. From this I draw the conclusion that the thing drawing the current in the timeslot stays active outside of the timeslot when constant latency is enabled.
Changing the prescaler of TIMER0 to 0 does increase the current consumption quite a lot, but changing to 1 does not increase the consumption a lot. Apparently, the consumption of the timer is more related to the prescalar intself than its clock source (PCLK1M vs PCLK16M).

RE: nRF52 idle current in timeslot

Thiemo van Engelen — Fri, 24 Mar 2017 14:18:51 GMT

It looks like the current is fully caused by TIMER0 and HFCLK, apparently requiring more current then specified in the product specification.

I concluded this by stopping TIMER0 (using TASKS_SHUTDOWN) a bit before really ending the timeslot by starting RTC2 on the TIMER0 interrupt, waiting 2msec for the RTC2 interrupt, signaling the RADIO interrupt, triggering a timeslot radio signal callback where the timeslot is ended and rescheduled. In the period between disabling TIMER0 and the real ending of the timeslot, the idle current was the same as when the timeslot was ended and thus much lower (200 uA) than when TIMER0 was still running.

Possible causes for the excess current consumption:

The current consumption of TIMER0 is a lot more than 5 uA. Perhaps the automatic selection of PCLK16M vs PCLK1M fails in this case. I will test this by setting the prescalar to 8 instead of 16. This should lead to increases current usage while the timer is running. If this is not the case, the automatic selection is faulty.
The current consumption of HFINT is a lot more than 60 uA
The HFXO is still running although HFCLKSTAT says that HFINT is used.

RE: nRF52 idle current in timeslot

Thiemo van Engelen — Fri, 24 Mar 2017 11:33:14 GMT

I found out that I did not have the DC/DC converter enabled. Enabling this reduces the difference to approx 200 uA. This still leaves around 130 uA unaccounted for, which apparently depends on the DC/DC converter regarding its power. Maybe this gives a clue on what it could be.

I did check the MWU when the timeslot enters starts and the REGIONEN register is 0, so no watches are enabled.

RE: nRF52 idle current in timeslot

Susheel Nuguru — Thu, 23 Mar 2017 21:24:55 GMT

most probably the memory watch unit (MWU) is consuming some more. PAN. I do not have source code at hand now, but it is possible that softdevice enables MWU when it gives control to application via timeslots. I can check later.