Split Host Controller changes from NCS 1.x to 2.x

[esisk]

Hello, my application is running on a custom board. The BLE Host is on an nRF9160, the BLE Controller is on an nRF52820, and the SoCs are connected via UART. On my original application, images for both SoCs were built using NCS 1.7.0. I'm attempting to upgrade the nRF9160 application to be built with NCS 2.4.2. I have not changed anything regarding my BLE setup, and I am unable to update the Controller in production. I'm having a lot of sporadic errors which will lead to data not being sent/received at all or my application crashing because the Controller hasn't responded. Here's some samples of logs that I've recently seen since updating:

<wrn> bt_gatt: write callback is deprecated, use subscribe cb instead
[00:00:09.152,557] <inf> ble: Conn params updated: interval 18 ms, latency 0, timeout: 3000 ms
[00:00:10.274,078] <wrn> bt_data: malformed advertising data 227 / 25
[00:00:10.274,108] <err> bt_driver: Unknown H:4 type 0xc6
[00:00:10.274,200] <err> bt_driver: Unknown H:4 type 0x71
[00:00:10.274,261] <err> bt_driver: Unknown H:4 type 0x29
[00:00:10.274,353] <err> bt_driver: Unknown H:4 type 0x81
[00:00:10.274,444] <err> bt_driver: Unknown H:4 type 0xdb
[00:00:10.274,536] <err> bt_driver: Unknown H:4 type 0xfb
[00:00:10.274,627] <err> bt_driver: Unknown H:4 type 0x49
[00:00:10.274,688] <err> bt_driver: Unknown H:4 type 0x0b

[00:00:03.187,438] <wrn> bt_driver: Failed to allocate, deferring to rx_thread
[00:00:03.228,973] <err> bt_driver: Unknown H:4 type 0x65
[00:00:03.228,973] <wrn> bt_data: malformed advertising data 193 / 126
[00:00:03.229,064] <err> bt_driver: Unknown H:4 type 0x61
[00:00:03.229,156] <err> bt_driver: Unknown H:4 type 0x63
[00:00:03.229,217] <err> bt_driver: Unknown H:4 type 0x6f
[00:00:03.229,309] <err> bt_driver: Unknown H:4 type 0x6e
[00:00:03.402,435] <wrn> data_mgr: Couldn't queue status msg id 4 err -67
[00:00:12.988,525] <wrn> data_mgr: Couldn't queue cert init msg id 4 err -67
[00:00:12.988,708] <wrn> data_mgr: Couldn't queue job get msg id 5 err -67
[00:00:12.989,318] <wrn> data_mgr: Couldn't queue status msg id 6 err -67
[00:00:13.579,681] <err> adv: CHECK IN WITH GW
[00:00:14.175,231] <wrn> ble: Curr conn is null
[00:00:14.185,485] <wrn> bt_driver: Failed to allocate, deferring to rx_thread
ASSERTION FAIL [err == 0] @ WEST_TOPDIR/zephyr/subsys/bluetooth/host/hci_core.c:330
  command opcode 0x2042 timeout with err -11
[00:00:24.175,445] <err> os: r0/a1:  0x00000003  r1/a2:  0x00000000  r2/a3:  0x00000002
[00:00:24.175,476] <err> os: r3/a4:  0x20019e58 r12/ip:  0x00000010 r14/lr:  0x000628b1
[00:00:24.175,476] <err> os:  xpsr:  0x41000000
[00:00:24.175,506] <err> os: s[ 0]:  0x00000000  s[ 1]:  0x00000000  s[ 2]:  0x00000000  s[ 3]:  0x00000000
[00:00:24.175,506] <err> os: s[ 4]:  0x00000000  s[ 5]:  0x00000000  s[ 6]:  0x00000000  s[ 7]:  0x00000000
[00:00:24.175,537] <err> os: s[ 8]:  0x00000000  s[ 9]:  0x00000000  s[10]:  0x00000000  s[11]:  0x00000000
[00:00:24.175,567] <err> os: s[12]:  0x00000000  s[13]:  0x00000000  s[14]:  0x00000000  s[15]:  0x00000000
[00:00:24.175,567] <err> os: fpscr:  0x00000000
[00:00:24.175,567] <err> os: Faulting instruction address (r15/pc): 0x000628bc
[00:00:24.175,628] <err> os: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
[00:00:24.175,659] <err> os: Current thread: 0x2001aaf8 (bt_rx_thread)
[00:00:24.589,843] <err> fatal_error: Resetting system

Here's the BLE startup info that's printed out at the beginning if that's helpful:

[00:00:02.791,351] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:02.791,381] <inf> bt_hci_core: HW Variant: nRF52x (0x0002)
[00:00:02.791,412] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 63.28743 Build 1318420878
[00:00:02.798,675] <inf> bt_hci_core: No ID address. App must call settings_load()
[00:00:02.798,675] <inf> ble: Bluetooth ready
[00:00:02.804,565] <inf> bt_hci_core: Identity: F6:6E:69:7A:7F:2B (random)
[00:00:02.804,595] <inf> bt_hci_core: HCI: version 5.2 (0x0b) revision 0x125b, manufacturer 0x0059
[00:00:02.804,626] <inf> bt_hci_core: LMP: version 5.2 (0x0b) subver 0x125b

My 2 questions are:

- Could someone help me diagnose the problem I'm having? Seems like a buffer is overflowing or there is not enough buffer space to send/receive the data I need. I don't know why that problem would show up since on the old NCS version everything would send just fine.

- Is it bad practice to have my 9160 app running with NCS 2.4.2 and the 52820 app running with NCS 1.7.0?

Thanks!

[Hieu]

Hi esisk,

- Could someone help me diagnose the problem I'm having? Seems like a buffer is overflowing or there is not enough buffer space to send/receive the data I need. I don't know why that problem would show up since on the old NCS version everything would send just fine.

Are you certain the log is from NCS v2.4.2? I can't find anywhere in v2.4.2 that produce that exact log. The closest is this spot
https://github.com/nrfconnect/sdk-zephyr/blob/v3.3.99-ncs1-1/subsys/bluetooth/host/hci_raw.c#L139-L141

Perhaps some terminal error added a colon between "H" and "4." Assuming that, it seems there is an issue with the connection between the host and the controller.

Could you please check what protocols each of them is using? I suspect one is using UART and the other is using LPUART.

- Is it bad practice to have my 9160 app running with NCS 2.4.2 and the 52820 app running with NCS 1.7.0?

We generally recommend using the Host and Controller from the same SDK version to ensure compatibility. While using Host and Controller from different releases, there is a high chance of incompatible due to change vendor-specific commands. Please try to at least disable CONFIG_BT_HCI_VS to prevent this. It's preferred to avoid this situation completely.

Hieu

[esisk]

In the VERSION file in my /nrf directory, the listed version is 2.4.2. Yeah possibly a terminal error. I never knowingly enabled LPUART, but it may have been accidentally enabled when I had to upgrade my board file. This is the pin control definition for the board used in the 9160 app:

    /* configuration for uart0 device, default state */
    uart0_default: uart0_default {
      /* group 1 ('group1' name is arbitrary) */
      group1 {
        psels = <NRF_PSEL(UART_TX, 0, 29)>, <NRF_PSEL(UART_RTS, 0, 24)>;
      };
      /* group 2 */
      group2 {
        psels = <NRF_PSEL(UART_RX, 0, 28)>, <NRF_PSEL(UART_CTS, 0, 26)>;
        // bias-pull-up;
      };
    };
    /* configuration for uart0 device, sleep state */
    uart0_sleep: uart0_sleep {
      /* group 1 ('group1' name is arbitrary) */
      group1 {
        psels = <NRF_PSEL(UART_TX, 0, 29)>, <NRF_PSEL(UART_RTS, 0, 24)>,
                <NRF_PSEL(UART_RX, 0, 28)>, <NRF_PSEL(UART_CTS, 0, 26)>;
        /* all pins are configured in low power mode */
        low-power-enable;
      };
    };

However, I see that the options CONFIG_UART_ASYNC_API and CONFIG_NRF_SW_LPUART_INT_DRIVEN are not set in my .config file in my build directory. The 52820 build doesn't have these options set either.

I set CONFIG_BT_HCI_VS=n and CONFIG_BT_HCI_VS_EXT=n and I'm still seeing the same problem

[Hieu]

Does the setup work at all if you flash a NCS v2.4.2 version of the HCI application on the nRF52820?

I mentioned CONFIG_BT_HCI_VS for general mixed SDK version setup. Right now, I think the problem is more likely communication, so it and CONFIG_BT_HCI_VS_EXT won't be relevant yet. Sorry, I should be clearer on this.

Could you please also check if CONFIG_BT_WAIT_NOP is set in both the nRF52820 and the nRF9160 application?