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]

Two questions: First, I have never heard of TWIM; is this something that you think would solve my issue? I will look into it if so.

Second, the code is complicated (asynchronous tasks; many), and there are many sensors. The only way I can imagine doing what you suggest, from a pragmatic perspective, is to keep a master TWI refcnt that is used by all the handlers, and to enable/disable TWI on the 0/1 and 1/0 transition of the refcnt (ie before the transfer and after the final outstanding callback). I can do this - it is just code - but I want to make sure I do it the right way. What are the specific Enable/Disable calls that you recommend using that would synchronously disable and enable the TWI subsystem? thx

[Einar Thorsrud]

TWIM is a new TWI master peripheral in the nRF52. Erratum 89 relates to that, and is not relevant in your case. If your code is indeed as complex as you write I think we would need more information in order to debug. The fact that the current consumption is as high as 5.5mA makes me wonder if the CPU is active (the CPU alone will typically use 3.7 - 3.9 mA when you have a DC/DC)?

Do you have an overview of which other peripherals and resources are active at the time?

[Ray]

Well, I've done further debugging.

1. I disabled GPIOTE completely thru conditional compilation. This had no effect.

2. I disabled app_uart completely thru conditional compilation. This brought my idle power down, as expected. So now, in the case where it is working well, the steady-state current draw of my test is approximately 1-2 microamps.

3. I removed all peripherals from the TWI bus except a single trivial peripheral, this one which is a MAX17043, and ensured that this is the only one that the software is trying to access. www.sparkfun.com/.../10617

4. I did an A/B test, where A initializes TWI but doesn't do any transactions, and B which initializes TWI but does a single transaction to the fuel gauge. In A, the battery voltage is 1-2 microamps. In B, the battery voltage increases to 6 milliAmps upon execution of the transaction. Note that the transaction is successful.

[Ray]

I should also add that I tried adding pullups to the TWI bus, which is a 3 inch pair of jumpers on a breadboard with the nRF52. The current draw is the same with or without the jumpers.

Finally, when the condition is occuring (the 6mA draw), I manually pulled ALL wires from the breadboard except power/gnd - including TWI wires - and the 6mA draw remains. This (obviously) shows that the 6mA draw is completely within the chip.

[Einar Thorsrud]

What do you do in your application after the TWI transfer? Could it be that you don't enter sleep (system ON low power mode)? Can you verify if that is the case?