This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

app_uart high sleep current issue

Hi, 

We are making software for our custom board based on nRF52833 and nRF5 SDK 17.0.2. We use app_uart for our serial communication in active mode and in sleep mode we disable the UART. Without APP_UART_FIFO_INIT the device's current consumption is about 2uA in sleep mode using nrf_pwr_mgmt_run(). When we initialize UART for serial communication, we have made sure to uninitilaze UART by calling app_uart_close function and set UART TX and UART RX pin to  INPUT_NOPULL before setting the device to sleep mode, but current that does not work. The sleep current consumption is now about 179uA. Here is our configurations for app_uart

//brief: uart settings:
static app_uart_comm_params_t comm_params = {
    .rx_pin_no    = UART_RX,
    .tx_pin_no    = UART_TX,
    .rts_pin_no   = 0xffffffff,
    .cts_pin_no   = 0xffffffff,
    .flow_control = APP_UART_FLOW_CONTROL_DISABLED,
    .use_parity   = false,
#if defined (UART_PRESENT)
    .baud_rate    = NRF_UART_BAUDRATE_115200
#else
    .baud_rate    = NRF_UARTE_BAUDRATE_115200
#endif
};
APP_UART_FIFO_INIT(&comm_params,
                       DRV_UART_RX_BUFFER_SIZE,
                       DRV_UART_TX_BUFFER_SIZE,
                       uart_callback_handle,
                       APP_IRQ_PRIORITY_LOWEST,
                       err_code);

Parents
  • Hello,

    You say you have set the TX and RX pin to INPUT_NOPULL. Can you please try to set them to disconnected inputs, which is the default state that the pins are in when you turn on the nRF. Please see:

    https://infocenter.nordicsemi.com/topic/ps_nrf52833/gpio.html?cp=4_1_0_5_7_1_9#register.PIN_CNF-0-31

    If that doesn't work, can you show me how you set the pin configuration before you go to sleep?

    Best regards,

    Edvin

  • Hi!

    I happened to fix this problem by applied the following code snippet as a workaround to uart driver before I set the device to sleep and it works.

        *(volatile uint32_t *)0x40002FFC = 0;
        *(volatile uint32_t *)0x40002FFC;
        *(volatile uint32_t *)0x40002FFC = 1;
    The weird thing is that errata 89 applies to the issue with nRF52840 SoC whereas I'm using nRF52833 QIAAA0 version. I don't get it why the above workaround could fix the issue with the SoC I'm using or does the issue in errata 89 apply to nRF52833 QIAAA0 as well? 
    If I just this workaround, will it work the newer versions of nRF52833 SoC? 
  • Hello,

    John said:
    It turns out to be the problem with the SoC itself as reported in errata 89 GPIOTE: Static 400 µA current while using GPIOTE

    How did you determine that this was the issue? Did you apply the workaround, and the issue disappeared?

    If you did try it, I believe this is just a coincidence. The 0x40002nnn belongs to the UART registers in the nRF52833, and not the GPIOTE peripheral. I would imagine that this register does something similar to what is described in the errata, but for a different peripheral.

    What this suggests is that before you attempted this, your UART was not properly shut down, and it was still drawing some current.

    How did you disable the UART before going to sleep? Did you use the app_uart_close()? Depending on your setup, does that call nrfx_uarte_uninit() or nrfx_uart_uninit()?

    BR,

    Edvin

  • Hi,

    Now I found out that it was not the issue reported in "errata 89 GPIOTE: Static 400 µA current while using GPIOTE". I read it wrong so I withdraw this assumption. 

    Here is the code I use to disable UART before going to sleep

    
    

    app_uart_close();
    
    // workaround for app_uart issue 
    // https://devzone.nordicsemi.com/f/nordic-q-a/26030/how-to-reach-nrf52840-uarte-current-supply-specification/184882#184882
    *(volatile uint32_t *)0x40002FFC = 0;
    *(volatile uint32_t *)0x40002FFC;
    *(volatile uint32_t *)0x40002FFC = 1;
    

    
    

    Using app_uart_close() alone did not work. I had to apply the workaround described here https://devzone.nordicsemi.com/f/nordic-q-a/26030/how-to-reach-nrf52840-uarte-current-supply-specification/184882#184882 and now it works.

    So what is the issue with the nRF52833 SoC? Is this issue mentioned in nRF52833 errata?

    What is this register 0x40002FFC? I could not find the register information from nRF52833 datasheet.

  • Well, that didn't really answer my question.

    Just make sure that the GIPOs that you used for the UART is also set in disconnected input (default value) before you go to sleep. (this should be done in app_uart_close()).

    If it works for you, and the current consumption looks good, then it should be ok.

    Best regards,

    Edvin

  • Allright! I finally found the root cause for high sleep current consumption in my device. It was not the issue with app_uart_close nor the issue with the nRF52833 SoC. So using just  app_uart_close() is the proper setup before going to sleep. So we can close the topic here. Thank you so much for you help!

Reply
  • Allright! I finally found the root cause for high sleep current consumption in my device. It was not the issue with app_uart_close nor the issue with the nRF52833 SoC. So using just  app_uart_close() is the proper setup before going to sleep. So we can close the topic here. Thank you so much for you help!

Children
No Data
Related