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

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

Parents
  • Sorry for late reply Ben,

    I see that your main issue is 

     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 you are using a custom board, I would suggest that you try changing the gpio strength of those pins during initialization. 

    If this is on DK, help me reproduce it by sharing your project. 

  • Hi Susheel,

    Thanks for your reply!

    the gpio strength of those pins during initialization. 

    I have replaced the way to control led by using Zephyr API, and it works.

    We have discussed this issue too far afield. Let me simplify the problem. The current issue is a communication failure between appcore and netcore. After I finish burning the firmware, the following error often occurs upon reset.

    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)

    Best Regards!

  • You need to configure the network core properly as showin in similar threads shown here

  • Hi Susheel,

    From the posts you recommended, I found two potential causes for the -11 error:

    1. The DFU switch. I tried turning it off by CONFIG, but the error persists.

    2. Confirming that NetCore is flashing the correct image.

    Regardless of whether the DFU feature is enabled or disabled, the firmware name being flashed is always as follows:

    -- runners.nrfjprog: reset after flashing requested
    -- runners.nrfjprog: Flashing file: E:\project\nRF5340-master\build\merged_CPUNET.hex
    [ #################### ]   9.483s | Erase file - Done erasing                                                          
    [ #################### ]   1.155s | Program file - Done programming                                                    
    [ #################### ]   1.141s | Verify file - Done verifying                                                       
    Applying pin reset.
    -- runners.nrfjprog: Board with serial number 941000024 flashed successfully.
    -- west flash: using runner nrfjprog
    -- runners.nrfjprog: reset after flashing requested
    -- runners.nrfjprog: Flashing file: E:\project\nRF5340-master\build\merged.hex
    [ #################### ]   6.314s | Erase file - Done erasing                                                          
    [ #################### ]   1.336s | Program file - Done programming                                                    
    [ #################### ]   1.223s | Verify file - Done verifying

    Best Regards!

  • Add new found:

    I've found that the error doesn't seem to be caused by the reset itself. The error occurs if I don't open the RTT log (the VSCode view). If I open the log view after a reset, the logs appear normally.

    However, for normal factory programming, we cannot have the RTT viewer open. I tried using the nRF Programmer app to flash the firmware directly. After reset, the -11 error occurs.

Reply
  • Add new found:

    I've found that the error doesn't seem to be caused by the reset itself. The error occurs if I don't open the RTT log (the VSCode view). If I open the log view after a reset, the logs appear normally.

    However, for normal factory programming, we cannot have the RTT viewer open. I tried using the nRF Programmer app to flash the firmware directly. After reset, the -11 error occurs.

Children
  • Seems like with the logs there are some timing changes that gives the network core enough time to initialize.

    Can you set some delay before bt_enable in app core like k_sleep(K_MSEC(200)) and see if that helps? If it does, then we might change the priority of CONFIG_RPMSG_SERVICE_INIT_PRIORITY in prj.conf to see if this helps with network core being initialized a bit faster.

  • Hi Susheel,

    Thanks for your reply. I’ve observed a similar situation.


    Let me briefly explain how my previous program was executed: after the first reset, the system enters sleep mode, during which BLE is not enabled. BLE and the subsequent startup process are only activated when the system is woken up by a button press. The -11 error occurs at that moment.

    After a series of tests, I found that if I call bt_enable() immediately before system power off, the error no longer appears in the following process.

    Can you set some delay before bt_enable in app core like k_sleep(K_MSEC(200)) and see if that helps?

    This seems to be the opposite of your suggestion— in my case, calling bt_enable() earlier actually prevents the error.

    As a further question, is there a recommended or suggested time for calling bt_enable() on the nRF5340?

    Best Regards!

    Ben

Related