nRF52840 UART0 sleep current behavior

[dwanninger]

I have a custom board built around the nRF52840, which spends most of its life sleeping.  I'm able to achieve ~3uA current draw when it is sleeping, but I've recently started running into corner cases where the current draw is much higher.  I suspect that it is an issue with UART0.

As a specific example, if I disable UART0 and the other peripherals before going to sleep, I hit 3uA.  However, if I transmit on the UART just before disabling it, I see ~620uA of current in sleep.  Waiting on nrfx_uarte_tx_in_progress() and using delays does not seem to resolve the issue.

Here's a stripped down version of my code.  The "printf("Going to sleep...\r\n");" is the offending line.  If I comment that out, the sleep current is ok.  Any idea how to fix this?

int main(void)
{
    int32_t r;
    
    // Initialize HW peripherals
    r = HWC_UartInit();
    if(r) SC_printf("HWC_UartInit: failed to initialize (%i)\r\n", r);
    
    printf("Going to sleep...\r\n");

    // Uninitialize UART
    HWC_UartDeinit();
      
    __SEV();    // Send an event (guarantees an event is set)
    __WFE();    // Will wake up immediately, clearing the event
    __WFE();    // This will put the device to sleep for realzies

    // Reinitialize the UART
    HWC_UartInit();
    
    SC_printf("Awake again...\r\n");
        
    while(1);
}

int32_t HWC_UartInit()
{
    nrfx_uarte_config_t uartConfig = NRFX_UARTE_DEFAULT_CONFIG;

    uartConfig.pseltxd = PIN_UART_TX;
    uartConfig.pselrxd = PIN_UART_RX;
    uartConfig.hwfc = NRF_UARTE_HWFC_DISABLED;
    uartConfig.parity = NRF_UARTE_PARITY_EXCLUDED;
    uartConfig.baudrate = NRF_UARTE_BAUDRATE_115200;
    
    nrfx_err_t e = nrfx_uarte_init(&uartInstance, &uartConfig, HWC_UartEventHandle);
    if(NRFX_SUCCESS==e) e = nrfx_uarte_rx(&uartInstance, &rxByte, 1);
    
    return NRFX_SUCCESS == e ? 0 : -1;
}

void HWC_UartDeinit()
{
    nrfx_uarte_rx_abort(&uartInstance);
    nrfx_uarte_uninit(&uartInstance);
    
    // Need to restart UARTE0 to reduce power.  This may be related to an erratum.
    // devzone.nordicsemi.com/.../184882
    *(volatile uint32_t *)0x40002FFC = 0;
    *(volatile uint32_t *)0x40002FFC;
    *(volatile uint32_t *)0x40002FFC = 1;
}

[Jimmy Wong]

HI ,

if you use the UART, it needs to turn on the UART (50uA) from the Product spec + high frequency clock.

https://jimmywongbluetooth.wordpress.com/2019/04/17/overview-uart-driver-handling-at-nrf52/

I did some measurement on the Legacy UART or UART with DMA.

if you see more than 6xx uA, it should have other things on top of it.  

if you need to optimize the currrent consumption with UART particular on the UART RX, you may need to use extra gpio pin for control or use the timer to stop it.

[dwanninger]

I am disabling the UART, so I expect the MCU power consumption to be <3uA.  In some FW builds, it is.  In other cases, it is >600uA.  Something inconsistent is happening behind the scenes.  Perhaps a clock or DMA is not always being properly shutdown, or internal pulldowns are being enabled when they shouldn't be.

It's also possible that this isn't a UART issue at all.  But it seems to be the most likely culprit.  And again, in a stripped down version of the code running on the USB dongle with the UART as the only peripheral, I'm able to reproduce the issue.