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

user7377 — 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)

user101389 — 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?