nRF5340 Peripheral BLE connections always fail with reason 0x3e (62)

RE: nRF5340 Peripheral BLE connections always fail with reason 0x3e (62)

contax — Thu, 08 May 2025 09:33:52 GMT

Thanks, that thread helped!

RE: nRF5340 Peripheral BLE connections always fail with reason 0x3e (62)

mm784 — Tue, 05 Nov 2024 23:08:27 GMT

Thank you very much, this was extremely helpful!

RE: nRF5340 Peripheral BLE connections always fail with reason 0x3e (62)

Andriy Kostio — Thu, 12 Sep 2024 07:43:58 GMT

Thank you very much, this is very helpful.

RE: nRF5340 Peripheral BLE connections always fail with reason 0x3e (62)

dmerillat — Thu, 30 Mar 2023 21:00:20 GMT

Searches for those should start finding this ticket now. Glad it helped you.

RE: nRF5340 Peripheral BLE connections always fail with reason 0x3e (62)

Mike Pulice — Thu, 30 Mar 2023 20:57:24 GMT

Out of Tree Board: this is the symptom

bt_enable() fails with the following:

E: Endpoint binding failed with -11
E: HCI driver open failed (-11)

I need to go close the ticket I just opened. I'm so glad I found this post.
Thank you!!

RE: nRF5340 Peripheral BLE connections always fail with reason 0x3e (62)

dmerillat — Thu, 30 Mar 2023 20:53:55 GMT

Sorry. What were you trying to search for before finding it? I can add keywords to the original post to make it more discoverable.

RE: nRF5340 Peripheral BLE connections always fail with reason 0x3e (62)

Mike Pulice — Thu, 30 Mar 2023 20:50:00 GMT

I have to let my hair grow back from pulling it all out before finding your post!

I ad that configured for the app but had no idea it needed to be there for the net as well.

:(

RE: nRF5340 Peripheral BLE connections always fail with reason 0x3e (62)

Einar Thorsrud — Wed, 15 Dec 2021 08:59:20 GMT

Thank you for the suggestions. I agree with your points and have made an internal feature request for it.

RE: nRF5340 Peripheral BLE connections always fail with reason 0x3e (62)

dmerillat — Tue, 14 Dec 2021 03:02:55 GMT

Two things would make this easier to debug. The first would be changing the loop that waits on the external crystal to have a max count, and fail out with a console/debug log error saying the 32khz crystal isn't working. Currently the SDK behavior is to spin forever with no messages.

The second would be to log an error if the 32khz clock isn't running when we expect it to be, again with a brief and searchable message. something like <err> 32KHZ clock not running - check K32SRC.

Making documentation on the startup sequence more discoverable might help as well. The quickstart assumes you're using the DK and doesn't discuss the details in depth, then the Board Porting Guide only mentions the system clock. The 32K clock may only be mentioned indirectly ("configure a tick source"?) and not expanded on.

Searching for CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC only finds hits on the Kconfig pages, so you have to know what you're looking for before you can find it.

This applies to some other parts of the initial bringup, such as fixed-purpose pins (NFC, LFXO) and that there's extra steps involved to configure them as GPIO aside from just setting them in the device tree. Searching for that issue finds many threads of people confused why some pins don't work, and all getting the same answer. There's a devicetree validator as part of the build process already, perhaps it could flag an error on trivial conflicts such as using pin0.00/0.01 while having CONFIG_SOC_ENABLE_LFXO=y?