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]

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.

[RK]

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