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

nRF52 idle current in timeslot

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

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

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

Children
No Data
Related