Disabling of UART Causing 8 mA increase in power draw

[rsoc16]

Hi. I  am implementing a low power operation in my firmware, but the UART de-initialization is causing me odd issues. In order to intialize, I call the function UART_Initialize() (placed below), and to de-initialize I call UART_DeInitialize() (also below). 

In doing this step of deinit, I add 8 mA current consumption. That obviously isnt right, but is there something dumb I am missing? I think I am following the correct process, but am open to any thoughts. 

To add, the function calls in the init and de-init below are unchanged from the SDK provided by Nordic.

Thank you!

uint32_t UART_Initialize(void)
{
    app_uart_comm_params_t const comm_params =
    {
        .rx_pin_no    = SMILERX_PIN_NUMBER,
        .tx_pin_no    = SMILETX_PIN_NUMBER,
        .flow_control = APP_UART_FLOW_CONTROL_DISABLED,
        .use_parity   = false,
        .baud_rate    = NRF_UART_BAUDRATE_115200
    };

    uint32_t rtncode_uart = 0;
    APP_UART_FIFO_INIT(&comm_params, UART_RX_BUF_SIZE, UART_TX_BUF_SIZE, uart_event_handle, APP_IRQ_PRIORITY_LOWEST, rtncode_uart);
    return rtncode_uart;
}

void UART_DeInitialize(void)
{
    nrfx_uarte_rx_abort();
    nrfx_uarte_tx_abort();
    app_uart_close();

    //https://devzone.nordicsemi.com/f/nordic-q-a/35510/uart-deinit-does-not-reduce-power-consumption-and-it-too-big-600ua
    //https://devzone.nordicsemi.com/f/nordic-q-a/26030/how-to-reach-nrf52840-uarte-current-supply-specification/102605#102605
    
    *(volatile uint32_t *)0x40002FFC = 0;
    *(volatile uint32_t *)0x40002FFC;
    *(volatile uint32_t *)0x40002FFC = 1;   
}

[Stian Røed Hafskjold]

If the current jumps up to 8mA, it's probably because you get an assert (CPU running in a loop). app_uart_close() returns a value. Check if it is successful or not.

nrfx_uarte_rx/tx_abort() should have the UART instance as an argument (is it really compiling without the argument?). https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.0.0/group__nrfx__uarte.html?cp=7_1_6_8_0_42_0_18#gada8aacc9576ce76945cda19f9525b187

The 0x40002FFC register workaround is not necessary if the rx and tx abort is handled correctly. The old driver version did not handle it correctly (hence the workaround in the post you were linking to), but this was fixed a while ago. So use the newest nrfx drivers and you should be good. No need for the workaround. Btw, which SDK version are you using?

[rsoc16]

After a little digging, the solution ended up being something obvious. The UART was still flushing data on deinitialization, which for some reason meant the power went up when i tried to deinit. I added a function to verify the UART has flushed all data before the deinit, and the code was good to go. De-initing the uart dropped the power draw ~1.5 mA