Mesh and peripheral coexistence nRF5340

[Fluke]

I need help with the example "ble_peripheral_lbs_coex "from the sdk-nrf V2.4.0 for the nRF5340.
I just added a hci_rpmsg.conf file in the child_image folder. with follow content:

# Copy controller configuration from prj.conf
CONFIG_BT_CTLR_DATA_LENGTH_MAX=37

# Disable unused Bluetooth features
CONFIG_BT_CTLR_DUP_FILTER_LEN=0
CONFIG_BT_CTLR_LE_ENC=n
CONFIG_BT_CTLR_CHAN_SEL_2=n
CONFIG_BT_CTLR_MIN_USED_CHAN=n
CONFIG_BT_CTLR_PRIVACY=n

The output is as follows:

---

Initializing...
[00:00:00.259,216] <inf> fs_nvs: 8 Sectors of 4096 bytes
[00:00:00.259,216] <inf> fs_nvs: alloc wra: 0, fa8
[00:00:00.259,246] <inf> fs_nvs: data wra: 0, 6c
[00:00:00.285,675] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:00.285,705] <inf> bt_hci_core: HW Variant: nRF53x (0x0003)
[00:00:00.285,736] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 224.11902 Build 2231721665
[00:00:00.286,285] <inf> bt_hci_core: No ID address. App must call settings_load()
Bluetooth initialized
[00:00:00.515,808] <inf> bt_hci_core: Identity: E9:9B:27:0A:4F:67 (random)
[00:00:00.515,838] <inf> bt_hci_core: HCI: version 5.4 (0x0d) revision 0x2077, manufacturer 0x0059
[00:00:00.515,869] <inf> bt_hci_core: LMP: version 5.4 (0x0d) subver 0x2077
Mesh initialized
Created a new identity for LBS: 1
ASSERTION FAIL @ WEST_TOPDIR/zephyr/subsys/bluetooth/host/hci_core.c:330
[00:00:10.534,912] <err> os: r0/a1: 0x00000003 r1/a2: 0x20002b50 r2/a3: 0x20002b50
[00:00:10.534,912] <err> os: r3/a4: 0x20003bd0 r12/ip: 0x00000003 r14/lr: 0x00006f7d
[00:00:10.534,942] <err> os: xpsr: 0x61000000
[00:00:10.534,942] <err> os: Faulting instruction address (r15/pc): 0x00006f88
[00:00:10.534,973] <err> os: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
[00:00:10.535,003] <err> os: Current thread: 0x20002b50 (unknown)
�*** Booting Zephyr OS build v3.3.99-ncs1 ***ng system

---

Apparently a timeout occurs in hci_core.c:
BT_ASSERT_MSG(err == 0, "command opcode 0x%04x timeout with err %d", opcode, err);

Can anyone please make the example compatible for the nrf5340? 

Thank you in advance, for your assistance.

Fluke

[Joakim Jakobsen]

Hi. 

Apologize for the long delay in response. 

As you can see from the documentation (https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.4.0/nrf/samples/bluetooth/mesh/ble_peripheral_lbs_coex/README.html)  this sample currently doesn't support the nRF5340, so I haven't tested this yet. 

I will try to get some time this week and see if I'm able to get the example working on the nRF5340.

Br, 
Joakim

[Fluke]

Hello,

have you had time to try out the example?

In the meantime I found out something else. If I reduce CONFIG_BT_ID_MAX from 2 to 1, the advertising works on both channels. However, only until I connect on BLE or do a provisioning. After that, advertising on the other channel no longer works. When I disconnect or perform a mesh reset (depending on how I was connected), then the advertising works again.

Kind regards
Fluke

[Fluke]

Hello?

Are you still working on a solution?

[Fluke]

I guess I found a workaround.
I came across it in the Mesh light example. There, besides Mesh, the SMP service is also started for a DFU. It is interesting that for the nrf53 the extended advertising does not work. However, point-to-point DFU over Bluetooth is supported by default. You only have to enable it via the Kconfig CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU. I have tested it and it works. What is not quite clear to me, the advertising is not explicitly started in the code?

you can test it yourself. Just use the example sdk-nrf/samples/bluetooth/mesh
/light the prj.conf with the following options extend with the nrf53 build:

# Enable point to point DFU over SMP
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y