btattach command hanging when using HCI UART sample nrf52840

Question

When flashing the chip with a build from the samples/bluetooth/hci_uart via west build -b nrf52840dk/nrf52840 samples/bluetooth/hci_uart --pristine and west flash off the current main of sdk-zephyr, a btattach command from a linux host connected to the Zephyr device over UART hangs indefinitely: 
 btattach -B /dev/ttyMSM` -S 1000000 -P h4 
 Attaching Primary controller to /dev/ttyMSM2 Switched line discipline from 0 to 15 = New Index: 00:00:00:00:00:00 (Primary,UART,hci1) #0 [hci1] 4311.006931 = Open Index: 00:00:00:00:00:00 [hci1] 4311.007519 < HCI Command: Reset (0x03|0x0003) plen 0 #1 [hci1] 4311.007671 Device index 1 attached 
 The bluez version is 5.54, zephyr-sdk is the latest. 
 Looking at the backtrace on the device via gdb shows the CPU as idle, and no attempts to access the UART are seen. When attempting to disable the config value CONFIG_BT_CTLR as suggested here , the build fails with the below error. What must be done to enable HCI UART support on the Zephyr device? 
 -- Zephyr version: 4.0.0-rc2 (/Users/samantha.cho/clones/zephyrproject/zephyr), build: v4.0.0-rc2-53-gb9fc4cc4151f
[139/144] Linking C executable zephyr/zephyr_pre0.elf
FAILED: zephyr/zephyr_pre0.elf zephyr/zephyr_pre0.map /Users/samantha.cho/clones/zephyrproject/build/zephyr/zephyr_pre0.map
: && ccache /Users/samantha.cho/zephyr-sdk-0.17.0/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc -gdwarf-4 -gdwarf-4 zephyr/CMakeFiles/zephyr_pre0.dir/misc/empty_file.c.obj -o zephyr/zephyr_pre0.elf zephyr/CMakeFiles/offsets.dir/./arch/arm/core/offsets/offsets.c.obj -T zephyr/linker_zephyr_pre0.cmd -Wl,-Map=/Users/samantha.cho/clones/zephyrproject/build/zephyr/zephyr_pre0.map -Wl,--whole-archive app/libapp.a zephyr/libzephyr.a zephyr/arch/common/libarch__common.a zephyr/arch/arch/arm/core/libarch__arm__core.a zephyr/arch/arch/arm/core/cortex_m/libarch__arm__core__cortex_m.a zephyr/arch/arch/arm/core/mpu/libarch__arm__core__mpu.a zephyr/lib/libc/picolibc/liblib__libc__picolibc.a zephyr/lib/libc/common/liblib__libc__common.a zephyr/lib/net_buf/liblib__net_buf.a zephyr/soc/soc/nrf52840/libsoc__nordic.a zephyr/subsys/bluetooth/common/libsubsys__bluetooth__common.a zephyr/subsys/bluetooth/host/libsubsys__bluetooth__host.a zephyr/drivers/clock_control/libdrivers__clock_control.a zephyr/drivers/gpio/libdrivers__gpio.a zephyr/drivers/pinctrl/libdrivers__pinctrl.a zephyr/drivers/serial/libdrivers__serial.a zephyr/drivers/timer/libdrivers__timer.a modules/hal_nordic/nrfx/libmodules__hal_nordic__nrfx.a modules/segger/libmodules__segger.a -Wl,--no-whole-archive zephyr/kernel/libkernel.a -L/Users/samantha.cho/clones/zephyrproject/build/zephyr zephyr/arch/common/libisr_tables.a -mcpu=cortex-m4 -mthumb -mabi=aapcs -mfp16-format=ieee -mtp=soft -fuse-ld=bfd -Wl,--gc-sections -Wl,--build-id=none -Wl,--sort-common=descending -Wl,--sort-section=alignment -Wl,-u,_OffsetAbsSyms -Wl,-u,_ConfigAbsSyms -nostdlib -static -Wl,-X -Wl,-N -Wl,--orphan-handling=warn -Wl,-no-pie -specs=picolibc.specs -DPICOLIBC_LONG_LONG_PRINTF_SCANF -L"/Users/samantha.cho/zephyr-sdk-0.17.0/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/thumb/v7e-m/nofp" -lc -lgcc && cd /Users/samantha.cho/clones/zephyrproject/build/zephyr && /opt/homebrew/Cellar/cmake/3.30.5/bin/cmake -E true
/Users/samantha.cho/zephyr-sdk-0.17.0/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: zephyr/subsys/bluetooth/host/libsubsys__bluetooth__host.a(hci_raw.c.obj):/Users/samantha.cho/clones/zephyrproject/zephyr/subsys/bluetooth/host/hci_raw.c:60: undefined reference to `__device_dts_ord_133'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

Vidar Berg · Accepted Answer

Hi, samanthacho said: he `btattach` command from the host, the DK responds with `0e 04 01 03 0c 00`, which I believe to be the successful completion of a reset of the BT controller. You are right. I made a HCI capture with btmon showing the command exchange when I run btattach and I see the same response to the reset command. HCI capture (can be viewed in Wireshark): btmon_trace_attach.pcapng samanthacho said: - subsequent requests are propagated to the BT controller, but the interrupt to attempt to send them is never triggered, thus the tx_isr is never called and no data is attempted to be transmitted over uart. Should the whole message be sent in tx_isr via the `uart_fifo_fill` function? If not, when are the rest of the bytes supposed to be transmitted? Also, when data is added via ` h4_send`, why is the interrupt to send the data via tx_isr not being triggered? Also is this statement in hci_uart/src/main.c correct? I see the same "spurious interrupt" message when enabling debug logging over RTT: 00:01:04.220,855] hci_uart: h4_send: buf 0x2000c544 type 1 len 7 [00:01:04.222,137] hci_uart: h4_read: read 1 req 1 [00:01:04.222,137] hci_uart: h4_read: read 1 req 3 [00:01:04.222,167] hci_uart: h4_read: read 2 req 2 [00:01:04.222,198] hci_uart: h4_read: read 0 req 2 [00:01:04.222,229] hci_uart: bt_uart_isr: spurious interrupt rx:0 tx:0 [00:01:04.223,419] hci_uart: h4_read: read 1 req 2 [00:01:04.223,449] hci_uart: h4_read: read 1 req 1 [00:01:04.223,449] hci_uart: rx_isr: putting RX packet in queue. [00:01:04.223,480] hci_uart: h4_read: read 0 req 1 [00:01:04.223,510] hci_uart: bt_uart_isr: spurious interrupt rx:0 tx:0 [00:01:04.223,632] hci_uart: h4_send: buf 0x2000c544 type 1 len 7 [00:01:04.232,543] hci_uart: h4_read: read 1 req 1 [00:01:04.232,574] hci_uart: h4_read: read 2 req 3 [00:01:04.232,604] hci_uart: h4_read: read 0 req 1 [00:01:04.232,635] hci_uart: bt_uart_isr: spurious interrupt rx:0 tx:0 [00:01:04.235,870] hci_uart: h4_read: read 1 req 1 [00:01:04.235,900] hci_uart: h4_read: read 0 req 0 [00:01:04.235,931] hci_uart: rx_isr: putting RX packet in queue. [00:01:04.236,053] hci_uart: h4_send: buf 0x2000c544 type 1 len 15 I assume maybe the code is triggering the TX interrupt when it is not supposed to, but have not been able to confirm that yet. However, it does not seem to affect the HCI communication. I can still scan for devices in btmgr (with 'find -l') But it is strange that the tx fifo is not being emptied in your case. It makes me suspect that could be an issue with the flow control. Could you try updating your sdk to the v2.8.0-rc2 tag and try the HCI 3-wire (H:5) sample without flow control? Note that this sample requires you to use the hciattach command to attach the device. sudo hciattach -n /dev/ttyACM0 3wire 1000000 v2.7.0/nrf$ git fetch v2.7.0/nrf$ git checkout v2.8.0-rc2 v2.7.0/nrf$ west update Edit: Another way to check if this issue is caused by flow control is to lower the baud rate in the board overlay from 1M to 115200 and disable hardware flow control in your existing project. Although it may not be stable without flow control, you should be able to receive command responses if flow control is the problem.

btattach command hanging when using HCI UART sample nrf52840

Top Replies