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]

The model of the application is fairly straightforward:

• During init in main(), including doing things such as TWI_INIT, the app scheduler and timer are initialized as follows:

  APP_SCHED_INIT(SCHED_MAX_EVENT_DATA_SIZE, SCHED_QUEUE_SIZE);

  APP_TIMER_APPSH_INIT(APP_TIMER_PRESCALER, APP_TIMER_OP_QUEUE_SIZE, true);

  app_timer_create(&main_timer, APP_TIMER_MODE_REPEATED, main_timer_handler);

  app_timer_start(main_timer, TIMER_INTERVAL_15_SECONDS, NULL);

• Main() perpetually enters this loop.

  for (;;) {

    sd_app_evt_wait();
  

  app_sched_execute();

  }

• Everything in the app is driven off that 15s timer. Meaning,

1. Sometimes that timer callback will call a method that does a twi_schedule to measure a sensor, whose callback does nothing but to set a static variable with the measured value

2. Sometimes that 15s timer handler will create other one-shot timers to do temporary work at a smaller interval than 15s

3. Sometimes that timer callback (but NOT in this limited test) will sample the measurements stored in statics, and will use UART (using AT-like commands) to asynchronously initite communications of those measurements to a service, via a state machine.

4. Sometimes (but NOT in this limited test program) the UART interrupt handler will call app_sched_event_put() to continue advancing the communications state machine safely outside the interrupt handler.

Even though there are many sensors etc, structurally is really overall a very simple app, and as you can see above it relies upon timers and the app scheduler to do all work, and relies upon the softdevice's event wait to wait for an event and to sleep when there is no event pending.

I hate to reiterate this, but this app is working fine on S130 and is failing on S132, so respectfully I find it unlikely that this issue is related to my app's overall structure - which I believe is conformant to the app design pattern that Nordic's examples suggest that I should use. (I may be using them wrong, but I believe that they are done correctly.)

Einar, may I propose something? If there is someone who is willing to work through this with me, can we take this offline and interact more directly? We can post the result here after we figure out the source of the issue.

I have been called out of town and can't do work until the first week of Sept, but at that time I am open to using/reducing my source code to create a small sample app that exhibits the problem - if indeed someone on the Nordic side is willing to work directly with me to wrangle this.

If this might work for you and Nordic, can we take this to email?