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]

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?

[Einar Thorsrud]

I do not see anything in what you describe that should explain the high current consumption, so we should probably dig further. As you had almost identical code for the nRF51 without any issue, I am tempted to think that you may have triggered some errata, but I cannot say for sure. If you would like more direct support and share your code with Nordic in confidentiality, I suggest you open a support case in My page and refer to this thread.

[Ray]

I will first reduce a scratch copy of the source code to the simplest repro, then will do exactly /sys you suggest. Thank you.

[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

[RK]

"sd_app_evt_wait() never waits" is new information. Are you doing any floating point work, any at all? If you are have you seen this thread from yesterday where, after a bit of digging, as suspected right at the start, the FPU exception was keeping the device from sleeping.