Bluetooth HCI lpuart issue - nRF9160 + nRF52840

RE: Bluetooth HCI lpuart issue - nRF9160 + nRF52840

miceuz — Thu, 12 Sep 2024 10:50:05 GMT

Can you share how to implement hadware flow control?

I have this in my overlay file:

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

&uart1 {
 current-speed = <1000000>;
 status = "okay";
 hw-flow-control;

 pinctrl-0 = <&uart1_default_alt>;
 pinctrl-1 = <&uart1_sleep_alt>;
 pinctrl-names = "default", "sleep";
 // lpuart: nrf-sw-lpuart {
 // compatible = "nordic,nrf-sw-lpuart";
 // status = "okay";
 // req-pin = <24>;
 // rdy-pin = <25>;
 // };
};

and this in my thingy conf file:

# CONFIG_NRF_SW_LPUART=y
# CONFIG_NRF_SW_LPUART_INT_DRIVEN=y

# CONFIG_UART_1_ASYNC=y
CONFIG_UART_1_INTERRUPT_DRIVEN=y
# CONFIG_UART_1_NRF_HW_ASYNC=y
# CONFIG_UART_1_NRF_HW_ASYNC_TIMER=2

I'm getting an assert though:

ASSERTION FAIL [err == 0] @ WEST_TOPDIR/zephyr/subsys/bluetooth/host/hci_core.c:333
command opcode 0x0c03 timeout with err -11

Assotiated line in hci_core is this:

 err = k_sem_take(&sync_sem, HCI_CMD_TIMEOUT);
 BT_ASSERT_MSG(err == 0, "command opcode 0x%04x timeout with err %d", opcode, err);

RE: Bluetooth HCI lpuart issue - nRF9160 + nRF52840

miceuz — Thu, 12 Sep 2024 09:34:51 GMT

I am experiencing the same issues when getting a quite intense stream of notifications from peripheral.

RE: Bluetooth HCI lpuart issue - nRF9160 + nRF52840

tdfilip — Fri, 06 Sep 2024 07:16:22 GMT

Hello, is there any update on that topic?

RE: Bluetooth HCI lpuart issue - nRF9160 + nRF52840

sfemat — Thu, 25 Jul 2024 15:21:58 GMT

I have a Thingy91 and facing the same errors

<wrn> lpuart: req pin low when expected high
[00:00:00.265,869] <err> lpuart: Empty receiver state:4

and constant crashes even by using the lte_ble_gateway sample + hci_lpuart. From the crashes there seems to be some sort of timeout in the hci communication with the 52840

RE: Bluetooth HCI lpuart issue - nRF9160 + nRF52840

tdfilip — Mon, 08 Jul 2024 08:29:34 GMT

I changed back HCI to use lpuart but with baudrate 1000000 and I applied both changes you linked but it didn't help. These logs show up while receiving the data with notifications:

<wrn> lpuart: req pin low when expected high
<err> lpuart: Empty receiver state:4
<err> bt_driver: Unknown H:4 type 0x00
<err> bt_driver: Unknown H:4 type 0x00
<wrn> bt_hci_core: Unexpected HOST_NUM_COMPLETED_PACKETS (status 0x0c)

Bluetooth stops working after that.

In addition, after adding modification to uart_nrf_sw_lpuart.c, application after power up goes to zephyr fatal error and logs:
ASSERTION FAIL [err == 0] @ WEST_TOPDIR/zephyr/subsys/bluetooth/host/hci_core.c:331
command opcode 0x0c03 timeout with err -11

After restart, bluetooth starts without problem.

RE: Bluetooth HCI lpuart issue - nRF9160 + nRF52840

Vidar Berg — Fri, 05 Jul 2024 07:47:51 GMT

Hi,

It seems like the HWFC control will interfere with the REQ/RDY handling in the LP UART implementation. However, I've discussed the case with one of the developers, and I thought your initial issue may have been caused by the bug addressed by this PR: https://github.com/nrfconnect/sdk-nrf/pull/14609. Could you please try to cherry-pick this commit and increase the receive buffer (https://github.com/nrfconnect/sdk-nrf/blob/ef120afe4d0d3e8a40c664f7f4c40881c456017b/drivers/serial/Kconfig.nrf_sw_lpuart#L41) to 512, then try again with your original project?

Best regards,

Vidar

RE: Bluetooth HCI lpuart issue - nRF9160 + nRF52840

tdfilip — Thu, 04 Jul 2024 12:38:25 GMT

After some debugging I can say that bt_gatt_write_without_response function blocks forever because it waits for being able to allocate network buffer (in file buf.c, function net_buf_alloc_len). The timeout for this operation is set to K_FOREVER in function bt_att_chan_create_pdu in file att.c. I tried to change the timeout to 1 second and disconnect if timeout happens. When the issue occured I disconnected and on each of the following connections, the network buffer could never be allocated again. Do you have any suggestions why would the network buffer become unavailable to be allocated forever?

Edit 1
I turned on CONFIG_NET_BUF_LOG and now if the issue occurs with timeout set to K_FOREVER I can see in logs:
<wrn> net_buf: bt_l2cap_create_pdu_timeout():645: Pool 0x2002081c low on buffers.
<wrn> net_buf: bt_l2cap_create_pdu_timeout():645: Pool 0x2002081c blocked for 1 secs
<wrn> net_buf: bt_l2cap_create_pdu_timeout():645: Pool 0x2002081c low on buffers.
<wrn> net_buf: bt_l2cap_create_pdu_timeout():645: Pool 0x2002081c blocked for 2 secs

and this shows up every second.

RE: Bluetooth HCI lpuart issue - nRF9160 + nRF52840

tdfilip — Wed, 03 Jul 2024 12:43:30 GMT

I would be grateful if you could look into 6 pins solution.

I'm testing my application with HWFC and 1000000 baudrate and I didn't see any issues from the origin post.

However, now I'm facing another issue which didn't occur before. During the connection I use bt_gatt_write_without_response function to send commands over bluetooth (10 bytes max). I execute it from my custom workqueue (based on the function description - if used from outside the BT RX thread, it acts like a blocking function) and randomly this function might block forever - it never returns. I don't see any related information in logs. This issue doesn't seem to occur when I change optimization from CONFIG_DEBUG_OPTIMIZATIONS to CONFIG_SIZE_OPTIMIZATIONS but I wouldn't take it as a solution. Do you think of any reason why would that happen?

RE: Bluetooth HCI lpuart issue - nRF9160 + nRF52840

Vidar Berg — Wed, 03 Jul 2024 12:23:06 GMT

I can't immediately think of any reasons why this would not work if you can afford to use the extra pins. I can look into it, but perhaps you should try stress testing your application again to verify if enabling HWFC fixed the reliability issues you had first.

RE: Bluetooth HCI lpuart issue - nRF9160 + nRF52840

tdfilip — Wed, 03 Jul 2024 09:25:32 GMT

Thank you, now the hardware flow control works with HCI.

Would it be possible to use lpuart with hardware flow control to lower the idle current consumption?
If I wired 6 pins between nRF91 and nRF52 (tx, rx, rts, cts, req, rdy) - would it make sense?

RE: Bluetooth HCI lpuart issue - nRF9160 + nRF52840

Vidar Berg — Tue, 02 Jul 2024 10:24:09 GMT

You need to use the interrupt-driven API as that is what is implemented in the HCI host driver.

RE: Bluetooth HCI lpuart issue - nRF9160 + nRF52840

tdfilip — Tue, 02 Jul 2024 09:46:28 GMT

I assume that this modification is also needed:

CONFIG_UART_2_ASYNC=y
CONFIG_UART_2_INTERRUPT_DRIVEN=n
CONFIG_UART_2_NRF_HW_ASYNC=y
CONFIG_UART_2_NRF_HW_ASYNC_TIMER=2

into

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

After above modification I still can't get bluetooth working with hardware flow control. Can you confirm that you can get bluetooth working on nRF9160dk using HCI_UART for nRF52 and LTE_BLE_GATEWAY for nRF91?

RE: Bluetooth HCI lpuart issue - nRF9160 + nRF52840

Vidar Berg — Tue, 02 Jul 2024 06:51:16 GMT

Sure. For the nrf9160 target, you can use these overlays:

#include <nrf9160dk_nrf52840_reset_on_if5.dtsi>
#include <nrf9160dk_uart1_on_if0_3.dtsi>

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

&uart1 {
	current-speed = <1000000>;
	hw-flow-control;
};

devzone.nordicsemi.com/.../nrf9160dk_5F00_nrf9160_5F00_ns_5F00_0_5F00_14_5F00_0.overlay

RE: Bluetooth HCI lpuart issue - nRF9160 + nRF52840

tdfilip — Mon, 01 Jul 2024 13:16:30 GMT

Could you show me what should be modified in .dts, .conf and _defconfig files in both nRF91 and nRF52 applications to make it use hardware flow control?

For nRF52 I followed HCI uart sample but I don't see any sample that shows how to configure nRF91 to work with HCI uart.

RE: Bluetooth HCI lpuart issue - nRF9160 + nRF52840

Vidar Berg — Thu, 27 Jun 2024 09:47:09 GMT

Sorry, I thought the host the was using the Async API, but I see the HCI driver uses the interrupt API, and I don't think it will help if the async API is only used on one side of the connection. I have reported the issues you have experienced internally. Another option would be to use the HCI uart sample with the regular driver and HW flow control, but then you will get an increased idle current as long as the BT stack is enabled, or run the whole BT application (host + controller) on the nRF52840 and only expose a custom command interface to the nRF9160 for sending and receiving BLE data.

RE: Bluetooth HCI lpuart issue - nRF9160 + nRF52840

tdfilip — Tue, 25 Jun 2024 10:38:11 GMT

Hello,

So, based on hci_uart_async I copied files main.c and hci_uart_async.c to my nRF52840 project and changed configuration to the following:

dts:

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

&pinctrl {
	uart1_default_alt: uart1_default_alt {
		group1 {
			psels = <NRF_PSEL(UART_TX, 0, 20)>,
					<NRF_PSEL(UART_RX, 0, 13)>,
					<NRF_PSEL(UART_RTS, 0, 14)>,
					<NRF_PSEL(UART_CTS, 0, 15)>;
		};
	};

	uart1_sleep_alt: uart1_sleep_alt {
		group1 {
			psels = <NRF_PSEL(UART_TX, 0, 20)>,
					<NRF_PSEL(UART_RX, 0, 13)>,
					<NRF_PSEL(UART_RTS, 0, 14)>,
					<NRF_PSEL(UART_CTS, 0, 15)>;
			low-power-enable;
		};
	};
};

bt_c2h_uart: &uart1 {
	status = "okay";
	current-speed = <1000000>;
	hw-flow-control;

	pinctrl-0 = <&uart1_default_alt>;
	pinctrl-1 = <&uart1_sleep_alt>;
	pinctrl-names = "default", "sleep";
};

prj.conf:

CONFIG_SERIAL=y
CONFIG_UART_ASYNC_API=y

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

CONFIG_BT_WAIT_NOP=y

CONFIG_BT_BUF_ACL_RX_SIZE=255
CONFIG_BT_BUF_ACL_TX_SIZE=255
CONFIG_BT_BUF_EVT_DISCARDABLE_SIZE=255

CONFIG_UART_CONSOLE=n

board_defconfig:

CONFIG_SOC_SERIES_NRF52X=y
CONFIG_SOC_NRF52840_QIAA=y
CONFIG_BOARD_xyz=y

CONFIG_ARM_MPU=y
CONFIG_HW_STACK_PROTECTION=y

CONFIG_GPIO=y
CONFIG_PINCTRL=y
CONFIG_MAIN_STACK_SIZE=1024
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=512

CONFIG_BT_TINYCRYPT_ECC=n
CONFIG_BT_CTLR_ASSERT_HANDLER=n

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

Now nRF9160 logs the following on system start and resets:

00> *** Booting nRF Connect SDK v3.5.99-ncs1-1 ***
00> [1970-01-01 00:00:03.039000]<wrn> bt_hci_core: opcode 0x0400 pool id 3 pool 0x20020974 != &hci_cmd_pool 0x200209cc
00> [1970-01-01 00:00:03.039000]<err> bt_driver: Unknown H:4 type 0x0e

Do I miss something in nRF52840 configuration? What should I change in nRF9160 configuration?

Also, is it possible to run hci_uart_async sample (nRF52840) and lte_ble_gateway sample (nRF9160) together on nrf9160dk? Should it work?

RE: Bluetooth HCI lpuart issue - nRF9160 + nRF52840

Vidar Berg — Fri, 21 Jun 2024 14:14:32 GMT

Hello,

Could you try to enable the LP UART driver in the HCI UART based on ASYNC UART sample instead? The ASYNC implementation should enable more reliable communcation at higher data rates than the interrupt-driven API.

RE: Bluetooth HCI lpuart issue - nRF9160 + nRF52840

tdfilip — Fri, 07 Jun 2024 07:04:45 GMT

[quote userid="4240" url="~/f/nordic-q-a/111838/bluetooth-hci-lpuart-issue---nrf9160-nrf52840/487750"]Is the application allowed to returned to the idle thread after you've sent the disconnect, or is it busy with other tasks? It unepexted if the disconnect callback never comes through. Are you observing any HCI errors when this happens?[/quote]

I put a log in an idle thread every second and I can see that after executing bt_conn_disconnect, idle thread still works. My other threads also work. No HCI errors observed in logs. The bt_conn_disconnect also doesn't return any error.

RE: Bluetooth HCI lpuart issue - nRF9160 + nRF52840

Vidar Berg — Thu, 06 Jun 2024 13:39:16 GMT

Hello,

I will try to see if I can replicate the HCI communication issues on my end, but did not get time to get started on that today. Will update the ticket when I have had a chance to try this.

[quote user=""]

To do it, I execute bt_conn_disconnect in a workqueue that handles notification data. Using sniffer, I can see that the disconnect command goes to the peripheral device and the connection ends. The problem is that I do not receive a disconnected callback. When I disconnect after receiving all the data, the disconnected callback is executed.

Any help would be greatly appreciated.

[/quote]

Is the application allowed to returned to the idle thread after you've sent the disconnect, or is it busy with other tasks? It unepexted if the disconnect callback never comes through. Are you observing any HCI errors when this happens?

Best regards,

Vidar