HCI Driver open failed - NRF5340

[jmilliken]

Hello,

We have been successfully developing and debugging an NRF5340 application for many months now. We have been logging data over BLE as well, so we know that was working. However, we recently started getting an error when trying to start the Bluetooth which seems to be unrecoverable. The specific failure point occurs in the call to bt_dev.drv->open() in hci_core.c. Following this down into the function call, I get a failure at these lines within rpmsg.c:

err = k_sem_take(&ipc_bound_sem, IPC_BOUND_TIMEOUT_IN_MS);

if (err) {

    BT_ERR("Endpoint binding failed with %d", err);

    return err;

}

I tried recovering the network and application cores with the nrfjprog command line tools. They seem to complete successfully, but it doesn't solve the problem.

One (potentially) important point - we recently tried implementing a shutdown feature that calls:

pm_state_set(PM_STATE_SOFT_OFF, 0);

After this was called is when the problem started. I don't know if it is related or not, but reading through some other threads, it seems like maybe the network core Flash could have been corrupted...? But if so, why don't the recover commands work? These should be completely erasing Flash, correct?

Any help is greatly appreciated. We are under a tight timeline and this error has introduced a major instability in the code base.

Thank you,

Jamie

[jmilliken]

Thanks. Regarding the debug link, it does sound like this could be the problem. The J-Link speed is set to 12MHz. I will try Ozone, but for VS Code debugging, how to do I specify the J-Link speed in the launch json?

[jmilliken]

Update - I managed to change the debug speed based on this answer and that was worked. I'm all set there, thank you for the help. I would like to go back to the other problem of not being able to use the most up to date SDK and toolchain to see if we can fix that as well.

[Susheel Nuguru]

Great to know that changing the speed of debug clock worked. Now back to you initial problem.

One (potentially) important point - we recently tried implementing a shutdown feature that calls:

pm_state_set(PM_STATE_SOFT_OFF, 0);

After this was called is when the problem started.

Did you configure a wakeup source? Without a wakeup source and making the chip go to system off will cutoff the debugger access well. System off is the deepest sleep state where most of the regulators are turned off including the one for the debugger clocks.