Custom board with external crystal is consuming too much power when powered down

[abvio]

Summary: My custom board with an external crystal is consuming 208 µA when powered down under Zephyr, and I need to reduce it to less than 20 or so.

My board is based on a Fanstel BT840, and includes an external crystal and capacitors as recommended in the data sheet. It uses Zephyr to manage tasks and converse over Bluetooth. It is powered by a coin cell.

I'm using a Nordic Powerkit II to measure current draw. When the device is awake and in use, it consumes about 370 µA, which is great and well within my spec. But when I enter deep sleep, it consumes 208 µA constantly.  The board works otherwise, which indicates to me that the internal clock is being used rather than the external crystal. 

This is under v1.9.1 of the Nordic SDK. My firmware includes MCU Boot for firmware updates.

My prj.conf includes the following lines:

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=n
CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_250PPM=y

To power down, I use the following code:

pm_power_state_force(0, (struct pm_state_info){PM_STATE_SOFT_OFF, 0, 0});

My research into this on the DevZone includes a post saying that I should expect single digit µA numbers for current draw:

The LF clock (either RC or crystal OSC) is the only clock source that is kept running continously. The 64MHz HF clock (sourced either internally or from the 32MHz crystal) is only enabled when necessary. This allows significant power saving: Chip uses single digit µA instead of a few 100µA in idle.

Any thoughts on how I can assure that the external crystal is being used for the clock and reduce power draw during sleep?

Thanks,

Steve

P.S. The complete prj.conf and the relevant part of the schematic is below. 

CONFIG_DEBUG=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_OPTIMIZATIONS=y

CONFIG_HEAP_MEM_POOL_SIZE=30000

CONFIG_PRINTK=y
CONFIG_ASSERT=y
CONFIG_SPI=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y
CONFIG_CONSOLE=y

CONFIG_THREAD_NAME=y
CONFIG_THREAD_ANALYZER=y
CONFIG_THREAD_ANALYZER_AUTO=y
CONFIG_THREAD_ANALYZER_RUN_UNLOCKED=y
CONFIG_THREAD_ANALYZER_USE_PRINTK=y

CONFIG_ASSERT=y
CONFIG_ASSERT_VERBOSE=y
CONFIG_ASSERT_NO_COND_INFO=n
CONFIG_ASSERT_NO_MSG_INFO=n
CONFIG_RESET_ON_FATAL_ERROR=n
CONFIG_THREAD_NAME=y

CONFIG_LOG=y
CONFIG_LOG_PRINTK=y

CONFIG_BT=y
CONFIG_BT_DEBUG_LOG=y
CONFIG_BT_SMP=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_BAS=y
CONFIG_BT_DEVICE_APPEARANCE=310

CONFIG_BT_DIS=y
CONFIG_BT_DIS_PNP=n
CONFIG_BT_DIS_MODEL="Abvio"
CONFIG_BT_DIS_MANUF="Abvio"
CONFIG_BT_DIS_SERIAL_NUMBER=y
CONFIG_BT_DIS_FW_REV=y
CONFIG_BT_DIS_HW_REV=y
CONFIG_BT_DIS_SERIAL_NUMBER_STR="1234"
CONFIG_BT_DIS_FW_REV_STR="1.0.22"
CONFIG_BT_DIS_HW_REV_STR="1"
CONFIG_BT_USER_DATA_LEN_UPDATE=y
CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS=n

CONFIG_BT_BUF_ACL_RX_SIZE=251
CONFIG_BT_GATT_CLIENT=y
CONFIG_BT_ATT_PREPARE_COUNT=2
CONFIG_BT_CONN_TX_MAX=10
CONFIG_BT_L2CAP_TX_BUF_COUNT=10
CONFIG_BT_L2CAP_TX_MTU=247
CONFIG_BT_L2CAP_DYNAMIC_CHANNEL=y
CONFIG_BT_CTLR_PHY_2M=y
CONFIG_BT_CTLR_RX_BUFFERS=2
CONFIG_BT_BUF_ACL_TX_COUNT=10
CONFIG_BT_BUF_ACL_TX_SIZE=251
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_DEVICE_NAME="Abvio"

CONFIG_PM=y
CONFIG_PM_DEVICE=y

CONFIG_MCUMGR=y
CONFIG_MCUMGR_CMD_IMG_MGMT=y
CONFIG_MCUMGR_CMD_OS_MGMT=y

CONFIG_BOOTLOADER_MCUBOOT=y

CONFIG_MCUMGR_SMP_BT=y
CONFIG_MCUMGR_SMP_BT_AUTHEN=n

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=n
CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_250PPM=y

[Einar Thorsrud]

Hi,

As long as the device stays in system off mode, the current consumption should be very low (in the order of 1 uA). However, there could be other parts of your board that contributes to the current consumption. Could that be the case? Another thing to check is the state of your GPIOs. These will retain the state when entering system off mode, so for instance an output pin set to high or low will still be in that state in system off mode. Therefor, there is a need to do a bit of clean-up before entering system off mode.

Any thoughts on how I can assure that the external crystal is being used for the clock and reduce power draw during sleep?

Even the LF clock is turned off in system OFF sleep mode (it is enabled in the system ON sleep mode though, which is the "normal" sleep mode). So that is not the case here. Regardless, in your config you have CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=y, so you are using the crystal (when the clock is running).

[abvio]

Thanks so much for your advice, Einar.  You were right. The circuit board was leaving a 3V signal on on the display, and even though the 5V VDD was powered down, the signal was drawing the extra current. After a little redesigning, the circuit is now consuming < 1 uA.  The Bluetooth modules were also damaged by overheated during reflow, which confused me a bit, but your original advice helped me narrow in on the actual problem. 

Steve