sd_app_evt_wait() doesn't give microamps consumption

[Jarmo]

Okay, I know there's a lot of threads about the subject. I have tried to read them all, with no help. My device still consumes 1.4 mA. Resetting does not help, so I assume it's not the debug-mode issue.

There's a lot of mentions that I should put all the peripherals I don't need into off state, before entering sd_app_evt_wait(). However, I cannot find any examples how to do that. That is, a piece of C-code how all those peripherals (UART, TWI etc.) can be configured into off state? Of course, such codes must exist somewhere, but why you cannot include them into all those answers? Links?

(If I put the whole system into off state using sd_power_system_off() I can reach 48 uA, which is quite reasonable due to other external peripherals we have on the board.)

Please help, I am quite frustrated... :(

[Jarmo]

It looks like at least UART is causing part of the issue. If I leave away this call: simple_uart_config(RTS_PIN_NUMBER, TX_PIN_NUMBER, CTS_PIN_NUMBER, RX_PIN_NUMBER, false)

The consumption drops to 100 uA and below. But since I need UART, I would like to know how to switch it off before entering sd_app_evt_wait()?

(By the way, those old-fashioned underscores make your code very hard to read because of visual unclarity. Consider switching to modern coding style, like SdApp_evtWait()...)

[RK]

NRF_TWI->POWER=0
NRF_UART->POWER=0

etc. turns modules entirely off

Of course once they are truly off they aren't going to do anything at all, send out data, send interrupts etc. Usually you don't want to power them off in order to enter app wait() (which is really just __wfe) but you want to power them off when they have finished doing their current task.

[RK]

If you read the product spec you'll see that while TX or RX are 'START'ed it needs the HF Clock which consumes lots of power (how much is in the product spec too). Using the simple uart code you'll see if you hunt through it that RX is started when you start the uart but only stopped when the uart deactivate call is called, and what that is depends a bit on which driver you're using. look for the TASKS_STOPRX task being written, that's what disables it again.

And the underscores are a very long-standing C convention. CamelCaseIsForJavaAndObjectiveCProgrammers. It's not modern, it's just different, and I'm sure you'll get very used to reading the underscores after a while.

[Jarmo]

Thanks, it looks like UART was using most of the power. Now I can achieve acceptable level :)

Yes, you are right that underscores are the traditional coding style for plain C. I got familiar with those at around 1988. It is really partially matter of what you get used to, but having read different kind of coding styles all these years, I personally favor camelCase. For my eyes, it is just more readable i.e. consumes less brain power... ;-) (I guess the difficulty to distinguish between a space and an underscore causes the incoherence.)

[Stefan Birnir Sverrisson]

Hi Jarmo

All peripherals are per default off, and only peripherals that have been explicitly enabled will be on at any time. I have updated the current consumption guide, section "Setup of SPI, UART, TWI interfaces" to more specifically address your concerns.

If you get 48uA in System OFF, that is not normal, that should be ~0.6uA. This leads to that you have leakage current either on a connected GPIO or programming interface. Try to disconnect all external circuits from the nRF51 and disconnect any potentially connected programmer. Have you gone through all the points in the "Troubleshooting" section in the current consumption guide.