How do I reduce power consumption on the UART interface

[duxinglang]

In one of my projects, UART interface is used for the communication of external sensors. During the power consumption test, I found that when 9160 enters the idle state, its average current is about 600uA.  However, after I turn off UART, the average current in Idle state is only less than 100uA. Therefore, what method can be used to reduce the power consumption of UART?  So it goes to sleep after the data has been transmitted or it shuts down automatically or something like that?  

this is my prj.conf file:

#
# Copyright (c) 2019 Nordic Semiconductor ASA
#
# SPDX-License-Identifier: LicenseRef-BSD-5-Clause-Nordic
#
# General config
CONFIG_NEWLIB_LIBC=y
CONFIG_NEWLIB_LIBC_FLOAT_PRINTF=y
CONFIG_ASSERT=y
CONFIG_REBOOT=y
CONFIG_GPIO=y
CONFIG_TRUSTED_EXECUTION_NONSECURE=y

# Log
CONFIG_LOG=y
CONFIG_LOG_IMMEDIATE=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_LOG_BACKEND_RTT=y
CONFIG_LOG_BACKEND_UART=n
CONFIG_LOG_DEFAULT_LEVEL=4
CONFIG_LOG_MODE_OVERFLOW=y
CONFIG_LOG_BACKEND_RTT_MODE_DROP=y
CONFIG_LOG_BACKEND_SHOW_COLOR=n
CONFIG_LOG_BACKEND_FORMAT_TIMESTAMP=n

# Modem info
CONFIG_MODEM_INFO=y

# BSD library
CONFIG_BSD_LIBRARY=y
CONFIG_BSD_LIBRARY_TRACE_ENABLED=n

# Flash
CONFIG_FLASH=y
CONFIG_IMG_ERASE_PROGRESSIVELY=y

# NVS
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_NVS=y
CONFIG_NVS_LOG_LEVEL_DBG=y
CONFIG_MPU_ALLOW_FLASH_WRITE=y

# nRF Cloud
#CONFIG_CLOUD_API=y
#CONFIG_NRF_CLOUD=y
#CONFIG_NRF_CLOUD_LOG_LEVEL_DBG=y
#CONFIG_NRF_CLOUD_AGPS=y
# Needed for the cloud codec
#CONFIG_CJSON_LIB=y

# GPS
CONFIG_NRF9160_GPS=y
#CONFIG_GPS_USE_SIM=y
CONFIG_GPS_USE_EXTERNAL=y
CONFIG_GPS_DEV_NAME="NRF9160_GPS"
CONFIG_GPS_CONTROL_PSM_ENABLE_ON_START=y
CONFIG_GPS_CONTROL_FIRST_FIX_CHECK_DELAY=10
CONFIG_GPS_CONTROL_FIX_CHECK_INTERVAL=30
CONFIG_GPS_CONTROL_FIX_TRY_TIME=360
CONFIG_GPS_CONTROL_PSM_DISABLE_ON_STOP=n

# AT_CMD
#CONFIG_AT_HOST_LIBRARY=y
#CONFIG_UART_INTERRUPT_DRIVEN=y

# Console
CONFIG_CONSOLE_SUBSYS=n
CONFIG_CONSOLE_HANDLER=n
CONFIG_CONSOLE_GETCHAR=n
CONFIG_CONSOLE=n
CONFIG_RTT_CONSOLE=n
CONFIG_UART_CONSOLE=n

# Enable SUPL client support AGPS
CONFIG_SUPL_CLIENT_LIB=n

# Network
CONFIG_NETWORKING=y
CONFIG_NET_NATIVE=n
CONFIG_NET_SOCKETS_OFFLOAD=y
CONFIG_NET_SOCKETS=y
CONFIG_NET_SOCKETS_POSIX_NAMES=y

# LTE link control
CONFIG_LTE_LINK_CONTROL=y
CONFIG_LTE_AUTO_INIT_AND_CONNECT=n
CONFIG_LTE_NETWORK_USE_FALLBACK=n
CONFIG_LTE_NETWORK_TIMEOUT=600
CONFIG_LTE_NETWORK_MODE_LTE_M_GPS=n
CONFIG_LTE_NETWORK_MODE_NBIOT_GPS=y
CONFIG_LTE_LEGACY_PCO_MODE=y

# PSM
CONFIG_LTE_PSM_ENABLE=y
CONFIG_LTE_PSM_REQ_RPTAU="00100001"
CONFIG_LTE_PSM_REQ_RAT="00000000"

# eDRX
CONFIG_LTE_EDRX_ENABLE=n
CONFIG_LTE_EDRX_REQ_VALUE="1001"

# RAI
CONFIG_LTE_RAI_ENABLE=y

# MQTT
CONFIG_MQTT_LIB=y
CONFIG_MQTT_LIB_TLS=n
CONFIG_MQTT_PUB_TOPIC="device/auri/pushdata"
CONFIG_MQTT_SUB_TOPIC="device/auri/"
CONFIG_MQTT_CLIENT_ID="my-client-id"
CONFIG_MQTT_USER_NAME="admin123"
CONFIG_MQTT_PASSWORD="admin123"
CONFIG_MQTT_BROKER_HOSTNAME="47.107.51.89"
#CONFIG_MQTT_BROKER_HOSTNAME="18.135.53.53"
CONFIG_MQTT_BROKER_PORT=1883
CONFIG_MQTT_KEEPALIVE=300

# Library for buttons and LEDs
CONFIG_DK_LIBRARY=y
CONFIG_DK_LIBRARY_INVERT_LEDS=n

# Heap and stacks
CONFIG_HEAP_MEM_POOL_SIZE=16384
CONFIG_MAIN_STACK_SIZE=8192
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048
CONFIG_HW_STACK_PROTECTION=y

# MCUBOOT
#CONFIG_BOOTLOADER_MCUBOOT=y
#CONFIG_IMG_MANAGER=y
#CONFIG_MCUBOOT_IMG_MANAGER=y

# SPI
CONFIG_SPI=y
CONFIG_SPI_NRFX=y
CONFIG_SPI_2=y
CONFIG_SPI_2_NRF_SPIM=y
CONFIG_SPI_3=y
CONFIG_SPI_3_NRF_SPIM=y

# I2C
CONFIG_I2C=y
CONFIG_I2C_NRFX=y
CONFIG_I2C_1=y
CONFIG_I2C_1_NRF_TWIM=y
CONFIG_I2C_2=n
CONFIG_I2C_2_NRF_TWIM=n
CONFIG_I2C_INIT_PRIORITY=60

# UART
#CONFIG_SERIAL=y
#CONFIG_UART_INTERRUPT_DRIVEN=y
#CONFIG_UART_LINE_CTRL=y
#CONFIG_UART_0_NRF_UART=y
#CONFIG_UART_0_NRF_UARTE=y
#CONFIG_UART_0_NRF_FLOW_CONTROL=n
#CONFIG_UART_1_NRF_UARTE=n
#CONFIG_UART_1_NRF_FLOW_CONTROL=n

# WIFI
CONFIG_WIFI=y

# Use smaller buffers for net_buf as CANBUS packets are quite small.
CONFIG_NET_BUF_DATA_SIZE=64
CONFIG_NET_BUF_USER_DATA_SIZE=1

#CONFIG_LOG=n
CONFIG_SERIAL=n

   

[Simon]

The link provided by Adeel is a useful one, take a look at that. The reason UART uses that much power is because the RX pin is constantly on (don't know when the connected device will send data), which needs the HF-clock. The HF-clock uses about 500uA-1mA. If you don't need the RX pin (e.g. only using uart for logging) you can simply disable it like explained here: https://devzone.nordicsemi.com/f/nordic-q-a/64532/nrf52840-peripheral_uart-low-power-ncs-1-3-0/279199#279199 

Another option is to use the low power uart driver, which will make the slave send a signal to a pin before transmitting and RX can be turned off while not in use. Check out the Low Power UART sample, which demonstrate how to use this driver.

Best regards,

Simon

[duxinglang]

Thanks for your reply!

I tried to call a function to let the uart enter sleep and wake up to reduce the power consumption, but I found that when my uart entered the state of low power consumption, I executed several keystrokes and the system crashed. Why?  

This is my code:

void uart_sleep_out(void)
{
#ifdef CONFIG_DEVICE_POWER_MANAGEMENT
	int err;

	err = device_set_power_state(uart_ble, DEVICE_PM_ACTIVE_STATE, NULL, NULL);
	if(err)
		LOG_INF("uart set active fail!\n");
	else
		LOG_INF("uart set active success!\n");
#endif
}

void uart_sleep_in(void)
{
#ifdef CONFIG_DEVICE_POWER_MANAGEMENT
	int err;

	err = device_set_power_state(uart_ble, DEVICE_PM_SUSPEND_STATE, NULL, NULL);
	if(err)
		LOG_INF("uart set low power fail!\n");
	else
		LOG_INF("uart set low power success!\n");
#endif
}

[duxinglang]

Maybe it has something to do with Log sending, because after I shut down all the logs, this problem doesn't seem to appear again, but I found a new problem, that is, if I use the timer to automatically hibernate the UART, and then press the button to wake up the UART, it will still enter the crash state, why?

[duxinglang]

Now, i can confirm that it wasn't the log that caused the crash, it was the timer I used to make the UART sleep automatically, but strangely enough, if I hadn't set sleep in the timer timeout callback, this problem wouldn't have occurred, which is very strange!  

[Simon]

I would not recommend you to do much processing in timer interrupts. See this answer for more details: https://devzone.nordicsemi.com/support-private/support/271094#permalink=669503.

Instead you should offload it to a work queue (like done here) or offload it to another thread usin k_sem_give()/k_sem_take().

[duxinglang]

In fact, I only set the value of one variable in the timer callback function and nothing more.  Later, I tried various operations and thought it was a system anomaly caused by the thread for some reason, because I found that everything was fine when the timer was sleeping the UART, but there was a problem waiting for me to wake the uart up again.  

[Simon]

Have you solved the issue? If not could you upload your application as a zipped file and I can take a look at it.

Best regards,

Simon