nrf52 > nrf51 power

RE: nrf52 > nrf51 power

RK — Wed, 31 Aug 2016 23:59:02 GMT

There aren't many gotchas in the nRF series, things you "just have to know', but this perhaps counts as one. But that's why the dev forums exist, so people can suggest things you may not have seen.

I've been a little hazy on why the FPU exception is different from others in that it keeps causing wfe() to return. I'd expect it to raise an exception which would return wfe() once, but not continually, and just the pending disabled exception shouldn't cause it to return immediately either.

I'm also not sure what Nordic can do about it. They could add logic to clear the FP flags if, for instance, the interrupt was not enabled before sleeping, however that's going to trip someone up in the future who doesn't have the interrupt enabled, but cares about FP exceptions. Perhaps sd_app_evt_wait() needs a parameter ..

RE: nrf52 > nrf51 power

Ray — Wed, 31 Aug 2016 23:35:14 GMT

Unbelievable. Yes indeed, that fixed the problem. THANK YOU.

I certainly have no reason to complain at this point because the problem is FIXED, but I must say I don't know how I would have avoided this. In searching the SDK for FPU_EXCEPTION_MASK (which is referenced by the code in the other thread), I found the entire explanation of the problem in the documentation/release_notes.txt, line 204 under ** FPU **.

I will now do a much more careful reading of the release notes on every SDK update.

(I am truly shocked that this isn't hitting the vast majority of users of the nRF52. I mean, using a float data type is likely a very, very common thing - and all these apps must certainly use sd_app_evt_wait(). It could in fact be that many, many apps are spinning in that loop and people just haven't noticed yet. Sigh!)

In any case, my deep appreciation for your assistance in wrangling this to the ground.

Now, only 1 incompatibility left; I can't quite get nRF52 DFU working yet. Well, ... that's for another day.

Thanks again and have a great holiday.

RE: nrf52 > nrf51 power

RK — Wed, 31 Aug 2016 23:01:17 GMT

"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.

RE: nrf52 > nrf51 power

Ray — Wed, 31 Aug 2016 20:20:21 GMT

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 891976 rate 10703712/min <-- power draw increases to >7mA

Events 892171 rate 10706052/min

Events 892008 rate 10704096/min

RE: nrf52 > nrf51 power

Ray — Fri, 26 Aug 2016 10:56:05 GMT

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

RE: nrf52 > nrf51 power

Einar Thorsrud — Fri, 26 Aug 2016 05:36:09 GMT

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.

RE: nrf52 > nrf51 power

Ray — Thu, 25 Aug 2016 12:24:19 GMT

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,

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
Sometimes that 15s timer handler will create other one-shot timers to do temporary work at a smaller interval than 15s
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.
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?

RE: nrf52 > nrf51 power

Einar Thorsrud — Thu, 25 Aug 2016 11:08:43 GMT

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?

RE: nrf52 > nrf51 power

Ray — Wed, 24 Aug 2016 14:28:00 GMT

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.

RE: nrf52 > nrf51 power

Ray — Wed, 24 Aug 2016 14:20:59 GMT

Well, I've done further debugging.

I disabled GPIOTE completely thru conditional compilation. This had no effect.
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.
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
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.

RE: nrf52 > nrf51 power

Einar Thorsrud — Wed, 24 Aug 2016 13:39:10 GMT

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?

RE: nrf52 > nrf51 power

Ray — Wed, 24 Aug 2016 13:27:51 GMT

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

RE: nrf52 > nrf51 power

Einar Thorsrud — Wed, 24 Aug 2016 13:02:31 GMT

From your nrf_drv_config.h it seems like you are using the TWI peripheral rather than the TWIM (which was introduced for nRF52), so it is not relevant after all. In any case I would recommend you to disable all peripherals which you do not need. You write that you will request sensor data every N minutes (i.e. very seldom). The I would try to disable the TWI peripheral between each time you use it to retrieve data from the sensors. The general idea is to keep as much of the chip resources disabled for as much of the time as possible.

RE: nrf52 > nrf51 power

Ray — Wed, 24 Aug 2016 12:53:01 GMT

I am about to leave on travel which suddenly got scheduled, but would of course like to pursue this and appreciate your engagement. I am sitting here right now at the bench and will try it. Can you just give me a little more info about the workaround? Meaning, this erratum seems to imply that the TWI is "disabled" under some circumstance. I need TWI to be constantly ON because there are sensors attached to the bus, and there are several timer/app-sch tasks that asynchronously request sensor values every N minutes. I'm just trying to understand at what exact point am I conceptually supposed to disable it / re-enable it? thx

RE: nrf52 > nrf51 power

Einar Thorsrud — Wed, 24 Aug 2016 12:38:31 GMT

Can you try the workaround and see if it helps?

RE: nrf52 > nrf51 power

Ray — Wed, 24 Aug 2016 12:09:15 GMT

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.

RE: nrf52 > nrf51 power

Einar Thorsrud — Wed, 24 Aug 2016 07:13:56 GMT

The current consumption numbers you write are higher than I would expect, even with the known errata. What other chip resources are active when you measure power? Is the CPU active or is the chip in a low power mode? Are you measuring the current consumption of only the chip, or does your measurements also include current consumption of other components on the board?

Are you using GPIOTE? The fact that you see an issue the moment you start the first TWI transfer leads me to think this is due to erratum 89. If that is the case, the following workaround should do the trick:

Turn the TWI off and back on after it has been disabled. To do so, write 0 followed by a 1 to the POWER register (address 0xFFC) of the TWI that needs to be disabled. Reconfiguration of TWI is required before next usage.