<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://devzone.nordicsemi.com/cfs-file/__key/system/syndication/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Uninitialising libuarte does not turn off EasyDMA, causing high current draw in sleep.</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/57027/uninitialising-libuarte-does-not-turn-off-easydma-causing-high-current-draw-in-sleep</link><description>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</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Wed, 29 Jan 2020 16:35:41 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/57027/uninitialising-libuarte-does-not-turn-off-easydma-causing-high-current-draw-in-sleep" /><item><title>RE: Uninitialising libuarte does not turn off EasyDMA, causing high current draw in sleep.</title><link>https://devzone.nordicsemi.com/thread/231744?ContentTypeID=1</link><pubDate>Wed, 29 Jan 2020 16:35:41 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:afb983d7-82d2-4b65-8c8a-e823b5193639</guid><dc:creator>PRvdO</dc:creator><description>&lt;p&gt;Thank you&amp;nbsp;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.&lt;/p&gt;
&lt;p&gt;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&amp;#39;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&amp;#39;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&amp;#39;re fully awake before sending it&amp;#39;s message otherwise we get framing errors.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Uninitialising libuarte does not turn off EasyDMA, causing high current draw in sleep.</title><link>https://devzone.nordicsemi.com/thread/231418?ContentTypeID=1</link><pubDate>Tue, 28 Jan 2020 13:25:23 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:5b77b5bc-5740-4c1a-a38a-6f3aead0e56b</guid><dc:creator>Stian R&amp;#248;ed Hafskjold</dc:creator><description>&lt;p&gt;Hi, please check out Sigurd&amp;#39;s answer in this thread, and particularly under the &amp;quot;Edit&amp;quot; part: &lt;a href="https://devzone.nordicsemi.com/f/nordic-q-a/54271/nrf52840-fails-to-go-to-low-power-mode-when-using-uart-rx-double-buffering"&gt;https://devzone.nordicsemi.com/f/nordic-q-a/54271/nrf52840-fails-to-go-to-low-power-mode-when-using-uart-rx-double-buffering&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;It&amp;#39;s actually not related to the bug in the Errata 89 as you linked to. It&amp;#39;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 &amp;quot;stuck DMA/HFCLK&amp;quot; symptoms.&lt;/p&gt;
&lt;p&gt;Anyways, the root cause for the stuck clock/DMA in the case of the UART is not hardware related at all, it&amp;#39;s just improper handling of some events in the UART driver. This is described in Sigurd&amp;#39;s answer.&lt;/p&gt;
&lt;p&gt;So, It&amp;#39;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: &lt;a href="https://github.com/NordicSemiconductor/nrfx/tree/v2.1.0"&gt;https://github.com/NordicSemiconductor/nrfx/tree/v2.1.0&lt;/a&gt; . Or you can apply the fix yourself as described in Sigurd&amp;#39;s answer.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>