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.

[Einar Thorsrud]

Can you try the workaround and see if it helps?