nrf52 > nrf51 power

[Ray]

I have looked around but have been unable to find doc explaining this. If there's something around, I'd truly appreciate a pointer.

I have an existing (solar powered) device that has been built using the nRF51822 + sdkv11 + s130.

In the stable test case that I use to benchmark, the steady-state draw is 0.456mA.

I am trying to upgrade to nRF52832. The hardware works quite well except for power.

My first attempt, of course, was to take the exact same nRF51822+sdkv11+s130 image and to load it onto the nRF52. It works quite well, and the power consumption is comparable or better than the nRF51 hardware.

I need to upgrade to the nRF52 natively, though, because I need the memory and speed. However, when I build the exact same code for nRF52+sdkv11+s132, the power draw is substantially more.

The first problem I ran into, and I just thought I'd let you and others know for posterity, is that in my nrf_drv_config.h I had decided to try easy_dma for the UART. Bad decision. When I turn on uart easy_dma, the current draw is 2.153mA. When I revert to "legacy", the current draw is back to 0.490mA. I am thus not blocked on this, and it's just an FYI that easy_dma represents a power regression.

The blocking issue I've run into, however, is TWI.

On the nRF51+sdkv11+s130, there is little or no power draw overhead by having TWI enabled, or by using it, so long as all devices you try to access actually exist on the bus.

However, on the nRF52+sdkv11+s132, the moment you do your first transfer (which is successful in my case), the power consumption skyrockets by approximately 5mA, and just stays there.

(No, I am not using easy_dma with TWI.)

Does anyone have a pointer to info that might explain this and potentially fix it? My hardware simply doesn't have the budget for 10x the power draw of the nRF51+s130. For now, I'm sticking with using the nRF51+s130 on the nRF52; assistance moving forward would be appreciated.

[Ray]

Thank you for your helpful and constructive answer. Indeed, the current consumption is 10x what it was in that errata.

Indeed I am initializing GPIOTE, but in this test case (where I minimize the complexity of the configuration so that I get stable test results) the GPIOTE is initialized but no interrupts are actually configured to be active.

However, unlike the errata, I am not using EASY DMA for TWI.

What I am measuring in this instance is the low-side current measured passing through the nRF52's ground pin (and also the nRF51 when I test that chip.) That is, the current here is just that of the CPU and not of the entire system.

And yes, it was kind of shocking to see the 5mA draw from just the CPU - which is why I began this hours-long quest to start turning things off until I could figure out the source of the drain.

(BTW - unrelated - the reason that the current draw from the CPU is as high as it is - that is, in the half-a-mA range rather than in the nA - is because of my need to use the UART. I have worked very hard to get UART usage down to the point where it was less than 1ma just by itself, but it is quite difficult. I am using hardware flow control, and now have easy DMA turned off. I had been hopeful when I saw easy_dma because of this issue, and I so wish Nordic could do some innovation in truly low-power UART because so many peripherals out there leave no alternative but to interface via UART and this causes a massive current drain in what would otherwise be a system whose draw would be in the 10's of nA.)

I can assure you that there are zero high-current loads attached to the GPIO pins. Please note as a reminder that in doing this A/B test, using the exact same software built from exactly the same makefile (but obviously with different .ld and compile params for cpu & -DNRF5*),

• nrf51 hardware + s130 + sdkv11 w/TWI == ~0.475mA current draw steady state
• nrf52 hardware + s130 + sdkv11 w/TWI == ~0.475mA current draw steady state
• nrf52 hardware + s132 + sdkv11 wo/TWI == ~0.475mA current draw steady state
• nrf52 hardware + s132 + sdkv11 w/TWI == ~5.5mA current draw steady state

FWIW, so that I don't leave out any details, here are the exact header files so that you may see precisely the configuration: www.dropbox.com/.../AACRhe9wzuNnvtAQe_PTpcIba

Again, thank you for your time.

[Ray]

Einar, FYI I did indeed file a support case ID 31290 in case you wish to track it.

You may be interested in knowing that I spent quite a bit of time reducing both the hardware config and my source code to the bare minimum required to repro the problem - all attached to the support request.

It's quite interesting in that immediately upon executing the very first TWI transaction, the reason the current consumption jumps to 7mA is that sd_app_evt_wait() never waits! When I put an event counter in the main loop, and display the event count/rate every 5 seconds, this is what I see. Pretty dramatic. In any case, I'm shifting my attention to the support case and am just pasting this here FYI. Thanks again for your help thus far.

sd_ble_enable: RAM START at 0x20002600

Events 26 rate 312/min <-- power draw stabilizes at <750uA

Events 24 rate 288/min

Events 24 rate 288/min

Events 891976 rate 10703712/min <-- power draw increases to >7mA

Events 892171 rate 10706052/min

Events 892008 rate 10704096/min