Problem with BLE Low Power Mode

[john_h]

Hello,

I am using nRF52832 and having a problem with the Low Power Mode. I am not sure if I am either not getting it to stay in low power mode when my UART is initialized, or if low power mode is using too much power.

When I do not even initialize the UART, my low power mode sees current usage in the 100s μA range

When I initialize my UART and then almost immediately uninitialize it, my sleep mode has a current draw of about 5-6mA. I have also disabled easy DMA to try to get the UART to use less power. Any ideas as to what is going on here? I have no other timers and am not connecting to it, so there should be no other events that wake it from this mode.

const app_uart_comm_params_t comm_params
    = { RX, TX, 0, 0, APP_UART_FLOW_CONTROL_DISABLED, false, UART_BAUDRATE_BAUDRATE_Baud115200 };
    
  uint32_t                     err_code;
  APP_UART_FIFO_INIT(&comm_params, UART_RX_BUF_SIZE, UART_TX_BUF_SIZE, uart_event_handle, APP_IRQ_PRIORITY_LOW,
                     err_code);
  error_code_check(err_code);
  APP_ERROR_CHECK(err_code);
  nrf_gpio_cfg(TX, NRF_GPIO_PIN_DIR_OUTPUT, NRF_GPIO_PIN_INPUT_DISCONNECT, NRF_GPIO_PIN_PULLUP, NRF_GPIO_PIN_H0D1,
               NRF_GPIO_PIN_NOSENSE);
  nrf_gpio_cfg(RX, NRF_GPIO_PIN_DIR_INPUT, NRF_GPIO_PIN_INPUT_DISCONNECT, NRF_GPIO_PIN_PULLUP, NRF_GPIO_PIN_H0D1,
               NRF_GPIO_PIN_NOSENSE);
               
//configure UART signal interrupt
  err_code = nrf_drv_gpiote_init();
  APP_ERROR_CHECK(err_code);

  nrf_drv_gpiote_in_config_t in_config = GPIOTE_CONFIG_IN_SENSE_LOTOHI(true);
  in_config.pull = NRF_GPIO_PIN_PULLDOWN;
  APP_ERROR_CHECK(err_code);

  err_code = nrf_drv_gpiote_in_init(UART_ALERT, &in_config, uart_alert_handler);
  APP_ERROR_CHECK(err_code);

  nrf_drv_gpiote_in_event_enable(UART_ALERT, true);


while(true) {
    nrf_drv_uart_rx_disable(&app_uart_inst);
    app_uart_close();
    nrf_drv_gpiote_in_event_disable(UART_ALERT);
    nrf_drv_gpiote_in_uninit(UART_ALERT);
    NRF_UART0->EVENTS_RXDRDY = 0;

    //need this delay to let it go to sleep
    nrf_delay_ms(1000);
    //NVIC_ClearPendingIRQ(UART1_IRQn);
    //NVIC_ClearPendingIRQ(GPIO_ODD_IRQn);
    sd_app_evt_wait();

}

I have confirmed that the GPIOTE is not the issue in a separate isolated test. It seems to be something with the UART either causing a much higher current draw or not allowing the board to remain asleep

[Susheel Nuguru]

seems like the uart uninit function is leaving something enabled. I would have to reproduce this tomorrow, which SDK version did you use? Is the code snippet you attached, enough for me to be able to reproduce this issue?

[john_h]

I think should be enough. I also have events for ble connections but shouldn't be an issue. I am using version 12.3 with s130

All my uart init/uninit is in uart library app_uart_fifo.c which is very similar to app_uart.c. I moved some of the code out of there and into this snippet just to make it more clear.

[Susheel Nuguru]

If this is all I need, then i will test this tomorrow morning as its pretty late here in Norway

[john_h]

As a note... I was able to get it into the lowest power mode when I switched to the non-FIFO uart. Is there any reason for this?

[Susheel Nuguru]

It looks like in your code snippet, you are trying to uninitialize the UART before you are calling app_uart_init.

Please check in a debugger to see if when using app_fifo and when calling nrf_drv_uart_rx_disable/app_uart_close fails with a return code and is stuck in the app_error handler?

[john_h]

Hi Aryan,

Looks like I have resolved this for now. Turns out that calling sd_app_evt_wait() twice does the trick and puts it into low power mode consistently.
Do you have any idea if the UART FIFO vs normal UART would have any affect on the low power mode?

[Susheel Nuguru]

UART with or without FIFO should work the same way power efficiency wise. UART FIFO just has very very tiny overhead of managing the buffer, but you should not see that big difference.

john_h said:

Turns out that calling sd_app_evt_wait() twice does the trick

This smells like a bug in the FIFO code somewhere. Thanks for the workaround, I did not find any other customer having this problem. I will anyways asks the team to do some power measurements on both to compare. Can we close this case John?