Thingy91 change to 1.9.x power usage baseline increases

RE: Thingy91 change to 1.9.x power usage baseline increases

Jared — Mon, 12 Jun 2023 14:27:48 GMT

Solution was:

Hi, I found the source of the 1.3mA. It's the HF crystal running. If you add NRF_CLOCK->TASKS_HFCLKSTOP = 1; in the ble_ready() callback, the current consumption goes down.

Not yet sure why this happens only after a power on reset, so I will have to dig into the drivers a bit more, but at least stopping the HFXO in the callback should be a good workaround for now.

RE: Thingy91 change to 1.9.x power usage baseline increases

Jared — Wed, 28 Dec 2022 16:48:26 GMT

It's definitely resetting properly! I've noticed that the current spikes once ble_enable is called. Our app otherwise runs as expected when BLE is not enabled. We are advertising and scanning periodically, even with this functionality cut out we're still seeing the high current.

I've uploaded the code to the private ticket. Thanks again for all your help!

RE: Thingy91 change to 1.9.x power usage baseline increases

Jared — Sun, 25 Dec 2022 13:52:33 GMT

Thank you so much for your feedback Stian Røed Hafskjold .

I was using the reset "device" to reset the nRF52. I'll double check the nRF91 is indeed resetting the nRF52. That may solve it for us right there!

RE: Thingy91 change to 1.9.x power usage baseline increases

Stian Røed Hafskjold — Fri, 23 Dec 2022 13:13:44 GMT

I tried with the hex files and I can see the same behavior. What I noticed is that if I only do a power on reset on the nRF91, the current drops. So it looks to me like the communication between the nRF52 and nRF91 gets stuck when both are reset at the same time. I.e. the nRF52 is not ready to receive/send data when the nRF91 is reset, and then the nRF91 get stuck in some kind of loop, or the UART transaction gets stuck, or something similar. If the nRF52 is already running when the nRF91 resets the current goes down to normal levels.

I will do some more research and get back to you. This could be an already known bug in the lp_hci_uart sample fixed in later NCS revisions, or it could have been introduced by your code changes. Anyways, if you are able to share the entire project in the private case, it could potentially speed up the process of finding the root cause, if it turns out that this is not caused by faulty drivers.

RE: Thingy91 change to 1.9.x power usage baseline increases

Jared — Thu, 22 Dec 2022 20:46:24 GMT

Re: GPIO register status:

❯ nrfjprog --memrd 0x50000700 --n 0x80 && nrfjprog --memrd 0x50000A00 --n 0x40
0x50000700: 00000000 00000000 00000000 00000000   |................|
0x50000710: 00000000 00000000 00000000 00000000   |................|
0x50000720: 00000000 00000000 00000000 00000000   |................|
0x50000730: 00000000 00000000 00000000 00000000   |................|
0x50000740: 00000000 00000000 00000000 00000000   |................|
0x50000750: 00000000 00000000 00000000 00000000   |................|
0x50000760: 00000000 00000000 00000000 00000000   |................|
0x50000770: 00000000 00000000 00000000 00000000   |................|
0x50000A00: 00000000 00000000 00000000 00000000   |................|
0x50000A10: 00000000 00000000 00000000 00000000   |................|
0x50000A20: 00000003 00000000 00000000 00000000   |................|
0x50000A30: 00000000 00000000 00000000 00000000   |................|

When I reboot it where it goes into the 1.3mA state it produces the same GPIO register output:

❯ nrfjprog --memrd 0x50000700 --n 0x80 && nrfjprog --memrd 0x50000A00 --n 0x40
0x50000700: 00000000 00000000 00000000 00000000   |................|
0x50000710: 00000000 00000000 00000000 00000000   |................|
0x50000720: 00000000 00000000 00000000 00000000   |................|
0x50000730: 00000000 00000000 00000000 00000000   |................|
0x50000740: 00000000 00000000 00000000 00000000   |................|
0x50000750: 00000000 00000000 00000000 00000000   |................|
0x50000760: 00000000 00000000 00000000 00000000   |................|
0x50000770: 00000000 00000000 00000000 00000000   |................|
0x50000A00: 00000000 00000000 00000000 00000000   |................|
0x50000A10: 00000000 00000000 00000000 00000000   |................|
0x50000A20: 00000003 00000000 00000000 00000000   |................|
0x50000A30: 00000000 00000000 00000000 00000000   |................|

RE: Thingy91 change to 1.9.x power usage baseline increases

Jared — Thu, 22 Dec 2022 20:27:20 GMT

[quote userid="4556" url="~/f/nordic-q-a/94798/thingy91-change-to-1-9-x-power-usage-baseline-increases/401982"]Can you also please post the hex files for your application, both the nRF52 and nRF91 hex files? Then I can try to flash them here and see if I can further narrow down the issue.[/quote]

You can check out the private ticket 300243 to get those files.

RE: Thingy91 change to 1.9.x power usage baseline increases

Jared — Thu, 22 Dec 2022 20:25:12 GMT

[quote userid="4556" url="~/f/nordic-q-a/94798/thingy91-change-to-1-9-x-power-usage-baseline-increases/401982"]Can you try to measure the current on the nRF91 and nRF52 current measurement headers, just to confirm that the current goes to the nRF91?[/quote]

Yup. Minus a small amount going to the nRF52 the bulk is going to the nRF91. This was one of the first things that I checked.

[quote userid="4556" url="~/f/nordic-q-a/94798/thingy91-change-to-1-9-x-power-usage-baseline-increases/401982"]When compiling for thingy91, the UART lines are routed to the nRF52, so that the nRF52 can be used as the UART to USB bridge. I'm thinking that maybe something could go wrong with this setup, and then only after a power on reset? Did you change anything on the nRF52 firmware, or did you unintentionally erase the firmware?[/quote]

We've been using the same code as the lp_hci_uart for the nRF52 side. See my configuration overlays and CMakeLists.txt

CONFIG_SERIAL=y
CONFIG_UART_INTERRUPT_DRIVEN=y

CONFIG_BT=y
CONFIG_BT_HCI_RAW=y
CONFIG_BT_HCI_RAW_H4=y
CONFIG_BT_HCI_RAW_H4_ENABLE=y

CONFIG_BT_EXT_ADV=y
CONFIG_BT_PER_ADV=y

# Mitigation for NCSIDB-356
CONFIG_BT_LL_SW_SPLIT=y
CONFIG_ZERO_LATENCY_IRQS=n

CONFIG_THREAD_NAME=y

# Fix scan issues (?)
CONFIG_ISR_STACK_SIZE=4092

# Override prj.conf defaults

CONFIG_BOOTLOADER_MCUBOOT=n
CONFIG_CONSOLE=n

CONFIG_GPIO=y
CONFIG_GPIO_AS_PINRESET=y

CONFIG_BT_CTLR=y
CONFIG_BT_WAIT_NOP=y
CONFIG_BT_MAX_CONN=16
CONFIG_BT_TINYCRYPT_ECC=n
CONFIG_BT_CTLR_ASSERT_HANDLER=y

CONFIG_UART_1_ASYNC=y
CONFIG_UART_1_INTERRUPT_DRIVEN=n
CONFIG_UART_1_NRF_HW_ASYNC=y
CONFIG_UART_1_NRF_HW_ASYNC_TIMER=2
CONFIG_NRF_SW_LPUART=y
CONFIG_NRF_SW_LPUART_INT_DRIVEN=y

/* SPDX-License-Identifier: Apache-2.0 */

&uart1 {
	current-speed = <1000000>;
	status = "okay";
	tx-pin = <25>;
	rx-pin = <32>;
	/delete-property/ rts-pin;
	/delete-property/ cts-pin;
	/delete-property/ hw-flow-control;

	lpuart: nrf-sw-lpuart {
		compatible = "nordic,nrf-sw-lpuart";
		status = "okay";
		label = "LPUART";
		req-pin = <22>;
		rdy-pin = <19>;
	};
};

/ {
	chosen {
		zephyr,bt-c2h-uart=&lpuart;
	};
};

&gpiote {
	interrupts = <6 NRF_DEFAULT_IRQ_PRIORITY>;
};

/* Disabling uart rx pin to get low power */
&uart0 {
	tx-pin = <6>;
	/delete-property/ rx-pin;
};

# SPDX-License-Identifier: Apache-2.0

cmake_minimum_required(VERSION 3.20.0)

find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
project(hci_lpuart)

# NORDIC SDK APP START
target_sources(app PRIVATE ${ZEPHYR_BASE}/samples/bluetooth/hci_uart/src/main.c)
# NORDIC SDK APP END

RE: Thingy91 change to 1.9.x power usage baseline increases

Stian Røed Hafskjold — Thu, 22 Dec 2022 15:26:29 GMT

Hi Jared,

Can you try to measure the current on the nRF91 and nRF52 current measurement headers, just to confirm that the current goes to the nRF91?

When compiling for thingy91, the UART lines are routed to the nRF52, so that the nRF52 can be used as the UART to USB bridge. I'm thinking that maybe something could go wrong with this setup, and then only after a power on reset? Did you change anything on the nRF52 firmware, or did you unintentionally erase the firmware?

You can also try to read out the GPIO configuration and compare with the schematics to see if any of the pins controlling other external components on the thingy91 have the wrong configuration. Please have a look at my answer here, and post the result from the GPIO register read out. Then I can help to check the configuration.

Can you also please post the hex files for your application, both the nRF52 and nRF91 hex files? Then I can try to flash them here and see if I can further narrow down the issue.

Thanks

RE: Thingy91 change to 1.9.x power usage baseline increases

Jared — Mon, 19 Dec 2022 18:15:25 GMT

Physical removal of the power to the Li-on pins, switching off the bench supply or switching off power from the PPK2 if i'm using that.

RE: Thingy91 change to 1.9.x power usage baseline increases

Hakon — Mon, 19 Dec 2022 16:09:39 GMT

How are you resetting?

RE: Thingy91 change to 1.9.x power usage baseline increases

Jared — Sat, 17 Dec 2022 15:11:41 GMT

Hi Hakon

No I don't. Power supply only at 4V. Connected directly to the Li-on pins.

RE: Thingy91 change to 1.9.x power usage baseline increases

Hakon — Fri, 16 Dec 2022 15:59:15 GMT

Do you have USB connected when measuring?

RE: Thingy91 change to 1.9.x power usage baseline increases

Jared — Thu, 15 Dec 2022 20:19:16 GMT

Still need some help on this one. I can program the board and it will operate as expected (low current during standby) but if I reset the board something latches and the board draws 1.3mA in the sleep state. Any insights are appreciated.

Debugger is disconnected during my testing and I'm providing 4.0V to LiON pins via the PPK

RE: Thingy91 change to 1.9.x power usage baseline increases

Jared — Wed, 14 Dec 2022 13:50:06 GMT

Yep did that too. Still need the console for RTT so I can't fully disable that but the pm_device APIs are super useful especially for dynamic applications! Thanks Achim Kraus

RE: Thingy91 change to 1.9.x power usage baseline increases

Achim Kraus — Wed, 14 Dec 2022 08:52:17 GMT

In the meantime I'm used to disable the UART in a dynamic way aligned with the sleep state of the modem.

CONFIG_PM_DEVICE=y

#include "power_manager.h"

static const struct device *const uart0_dev = DEVICE_DT_GET_OR_NULL(DT_CHOSEN(zephyr_console));

if (device_is_ready(uart0_dev)) {
 ret = pm_device_action_run(uart0_dev, PM_DEVICE_ACTION_SUSPEND);
}

I also switch the 3.3V with sleep mode.

The advantage is, that the logging can still be used in the active times.

RE: Thingy91 change to 1.9.x power usage baseline increases

Jared — Tue, 13 Dec 2022 13:25:28 GMT

After spending some time on this I think it's from either UART0 getting enabled by the bootloader or SPM. Disabling UART0 in both seemed to have done the trick.