nRF52 idle current in timeslot

[Thiemo van Engelen]

Hi,

I have an application running on a nRF52832, roughly based on the OpenMesh (github.com/.../nRF51-ble-bcast-mesh) code with respect to the timeslot API usage. In one test I disabled the RADIO and HF crystal and looked at the current consumption. The measured (idle) value during the timeslot was 375 uA more than the idle current outside of the timeslot. I expected the idle current in the timeslot to be a bit higher than the idle current outside of the timeslot, because TIMER0 is running, requiring 5 uA and this requires the internal HF clock, requiring 60 uA, but that does not count up to 375 uA. From the current it looks like the softdevice keeps another peripheral running during the timeslot , but I could not figure out which one. Does anybody perhaps have an idea?

Regards,

Thiemo van Engelen

[Susheel Nuguru]

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.

[Thiemo van Engelen]

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.

[Thiemo van Engelen]

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.

[Thiemo van Engelen]

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