Bluetooth init fails with error -11 after reset on nRF5340 (NCS v2.9.0)

[Ben_M]

Hi Nordic，

I encountered a strange issue when compiling and flashing my nRF5340 project with NCS v2.9.0.

• On the first flash, everything works fine. Bluetooth starts successfully.

• After I use VS Code "Reset" (without reflashing), the system reboots, but Bluetooth initialization fails with error -11.

Here are the logs for comparison:

First boot (works fine):

*** Booting nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***
[00:00:01.415,557] <inf> usb_cdc_acm: Device suspended
[00:00:01.431,976] <inf> ADS1299_log: ADS1299 init success  62
[00:00:01.451,660] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:01.451,690] <inf> bt_hci_core: HW Variant: nRF53x (0x0003)
[00:00:01.451,721] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 45.41337 Build 3074452168
[00:00:01.487,152] <inf> bt_hci_core: No ID address. App must call settings_load()
[00:00:01.488,403] <inf> bt_hci_core: Identity: DA:97:F9:91:41:A4 (random)
[00:00:01.488,433] <inf> bt_hci_core: HCI: version 6.0 (0x0e) revision 0x206b, manufacturer 0x0059
[00:00:01.488,464] <inf> bt_hci_core: LMP: version 6.0 (0x0e) subver 0x206b
[00:00:01.488,525] <err> bt_gatt: Failed to save Database Hash (err -2)
[00:00:01.488,800] <inf> main_thread_log: BT addr: DA:97:F9:91:41:A4

Second boot (after reset, Bluetooth fails):

*** Booting nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***
[00:00:01.511,138] <inf> usb_cdc_acm: Device suspended
[00:00:01.527,557] <inf> ADS1299_log: ADS1299 init success  62
[00:00:02.530,303] <err> bt_hci_driver: Endpoint binding failed with -11
[00:00:02.530,334] <err> bt_hci_core: HCI driver open failed (-11)
[00:00:02.530,364] <err> main_thread_log: Bluetooth init failed (err -11)

My questions:

1. Why does Bluetooth initialization succeed after the first flash but fail with -11 after a reset? Is there any additional configuration required for reset handling on nRF5340?

2. During the first boot, I also see:

   <err> bt_gatt: Failed to save Database Hash (err -2)

   What exactly does error -2 mean here? I have read in forum posts that this error might not affect usage — is this still the case with NCS v2.9.0, or should I configure settings/NVS properly to avoid it.

Thank you for your support!

Best Regards!

Ben

[Menon]

Hello,

I’ll try to see if I can reproduce this issue here. Before that, could you confirm whether you are seeing this issue with a Bluetooth sample from the SDK, or only with your custom application? Please let me know if it also occurs with any of the SDK samples, and I will try to reproduce it using the same sample on my side.

Kind regards,
Abhijith

[Ben_M]

Hi Menon,

Thanks for your reply! Let me clarify more information.

I am currently migrating an existing project for the nRF5340 (using a custom board and custom application) from NCS v2.6.0 to NCS v2.9.0. The project worked fine on v2.6.0, but after the update I have encountered several issues.

I have already:

• Rewritten the device tree based on the 2.9.0 SDK.

• Modified the child images to follow the new sysbuild method.

• Verified that the project compiles successfully and some basic functions are working.

But I am still facing the following problems:

1. Bluetooth reset issue

   • After flashing the firmware, the first reset works normally.

   • On the second reset, I see a BT HCI error and the system crashes into a dump.

   • Any subsequent reset will reproduce the same error until I re-flash the firmware.

2. SPI communication with ADS1299

   • The first step of the initialization procedure is to read the chip ID for connection verification.

   • I noticed that the ID reading is often incorrect or corrupted, although sometimes it is correct.

   • I double-checked the hardware connections and used an oscilloscope to capture the SPI waveform. The signal looks correct on the scope, but the software frequently receives invalid values.

Could you please help me identify what might be causing these issues? Any guidance on troubleshooting steps or known changes between NCS v2.6.0 and v2.9.0 that could explain this behavior would be greatly appreciated.

Thank you for your support.

Best regards,

[Ben_M]

I also noticed that some Nordic APIs seem not to work as expected in NCS v2.9.0.For example, when I configure pins such as P0.30 as LED control outputs and use functions for nrf5 SDK

nrf_gpio_pin_set();  
nrf_gpio_pin_clear();  

 in my code, I can see in the VS Code debug interface that the registers are updated (the pin is set/reset). But when I measure the actual pin with a multimeter, the voltage always stays low.

If I instead configure the same pin via the Zephyr device tree and GPIO driver bindings, the pin works correctly.

This raises two questions:

• Does this mean that Nordic intends to deprecate direct nrf_gpio_* usage in favor of Zephyr’s device-tree-based GPIO control?
• Could this issue also be related to implicit forwarding by the CPUNET core, similar to cases I have seen in other examples?

[Ben_M]

Update on Issue 2 (SPI communication with ADS1299):

When I lower the SPI clock speed to 8 MHz, the data becomes stable and no longer shows errors. I will continue  test it for confirm.

On NCS v2.6.0 I was able to run the SPI interface at 16 MHz without problems. Currently, I am using SPI4, according to the documentation should support speeds up to 32 MHz.

Is there any specific configuration or option that needs to be enabled in order to achieve stable operation at higher SPI frequencies?

[Ben_M]

Hi Abhijith,

Any update here?

Best Regards!

Ben