Uninitialising libuarte does not turn off EasyDMA, causing high current draw in sleep.

[PRvdO]

I am looking to use libuarte in our project. We are creating a battery powered device and so need to be low powered. EasyDMA draws about 1mA when running which is far too high.

The idea to get around this is to only enable the UARTE (and thus EasyDMA) when comms are required.

Currently I am just using the libuarte example project to test the power usage. I have modified the example to call nrf_libuarte_async_uninit() and then sleep once the Tx has finished. This still draws about 1mA of current even when sleeping, whereas, if I never initialise libuarte to start with then I get about 3uA!

This seems that EasyDMA is never actually being disabled when uninitialising the UARTE. I guess this is related to this known bug, however, this workaround is for the TWIM and SPIM.

My question is: how can I disable EasyDMA when it is not in use?

[Stian Røed Hafskjold]

Hi, please check out Sigurd's answer in this thread, and particularly under the "Edit" part: https://devzone.nordicsemi.com/f/nordic-q-a/54271/nrf52840-fails-to-go-to-low-power-mode-when-using-uart-rx-double-buffering

It's actually not related to the bug in the Errata 89 as you linked to. It's just that the workaround given in the errata is basically just a power cycle, which will release the HF clock and DMA bus, and the current will go down again. So the workaround in that errata is kind of a universal fix for the "stuck DMA/HFCLK" symptoms.

Anyways, the root cause for the stuck clock/DMA in the case of the UART is not hardware related at all, it's just improper handling of some events in the UART driver. This is described in Sigurd's answer.

So, It's much better to fix the root cause than to apply the Errata 89 workaround. The fix is now part of the 2.1 release of the nrfx drivers, which is located here: https://github.com/NordicSemiconductor/nrfx/tree/v2.1.0 . Or you can apply the fix yourself as described in Sigurd's answer.

[PRvdO]

Thank you Stian. That did seem to fix the problem with not sleeping. I had to manually patch the changes as v2.x.x of the HAL is not compatible with SDK v17.

Do you know of a way to reduce the 1mA drain of the UARTE? We need to be low powered so 1mA for a UART isn't really ideal. We would like to wake up on received data and then send a single response and then sleep again, this is not constant comms and so we don't need to always be active. The only way I can see to do this with the UARTE is to uninit the UARTE when not in use and instead enable a GPIOTE interrupt on the Rx line, then when we get data we enable the UARTE again to read the message. This is not great because the other device needs to wait until we're fully awake before sending it's message otherwise we get framing errors.