Random BLE disconnections and occasional system hang on nRF52832 using bare-metal SDK (external RTC used)

RE: Random BLE disconnections and occasional system hang on nRF52832 using bare-metal SDK (external RTC used)

Einar Thorsrud — Thu, 08 Jan 2026 08:12:23 GMT

Hi,

[quote user="Ramesh Polasa"]I can share the application logs if that helps.[/quote]

Yes, that will be very usefull. The Android devices sees a timeout, but that can be caused by a number of things. If there was a SoftDevice assert, or another unhandled error on the nRF side, that would terminate the link immediately, that would cause a timeout (disconnect reason 0x8) on the Android side.

There are also a number of other potential causes, such as inaccurate sleep clock, so it could be interesting to know your exact 32.768 kHz crystal and which load caps you have used. Though I would expect you should see problems more often if that was the rase.

[quote user="Ramesh Polasa"]What would you recommend as the next steps to narrow this down?[/quote]

Primarily I would start by error logging on the nRF, so that we can see if there are errors or asserts, or unexpected resets. A sniffer trace is also useful, this could show if the nRF simply stops responding (as would be the case of an error), or if the problem could be on the Android side.

[quote user="Ramesh Polasa"]What is the recommended way to capture callstack and register data if a HardFault or SoftDevice assert ever does occur? I’d like to add a simple blackbox-style capture so I can get the fault context even if the device freezes during long-term operation.[/quote]

In case of SoftDevice assert, log the PC of the assert that is passed to the error handler (see app_error_fault_handler() implementation). With this and the exact SoftDevice version I can look up which assert this was in the SoftDevice. For Hardfaults I would start with enabling the HardFault handling library as you have logging. This will then print information about the error in the log. Enable this by setting HARDFAULT_HANDLER_ENABLED to 1 in your sdk_config.h.

RE: Random BLE disconnections and occasional system hang on nRF52832 using bare-metal SDK (external RTC used)

Ramesh Polasa — Thu, 08 Jan 2026 07:38:59 GMT

devzone.nordicsemi.com/.../1362.NRF_5F00_LOG.txt devzone.nordicsemi.com/.../Log-2026_2D00_01_2D00_02-14_5F00_47_5F00_57.txt

Hi Einar,

Thanks for the explanation.

I have NRF logs (RTT-based) when the device is running under a debugger, but the issue is that it never hangs in that setup. The random disconnects and the occasional freeze only happen during long standalone runs, so I haven’t been able to capture a SoftDevice assert or a HardFault in the moment. The logs look normal right up to the disconnect.

About bonding: I did see the phone removing the bond on the Android side, but even when bonding isn’t involved, we still get “Error 8 (0x8): GATT CONN TIMEOUT.” In some long runs the device stops responding completely. It stops advertising and stops producing any logs, so it seems like something deeper than just bonding.

I can share the application logs if that helps.

What would you recommend as the next steps to narrow this down?
Should I:

Enable full PM event logging
Capture a sniffer trace (and if so, what should I focus on)
Add more SoftDevice and reset-reason logging
Monitor radio notifications for possible missed events

Also, one more question:
What is the recommended way to capture callstack and register data if a HardFault or SoftDevice assert ever does occur? I’d like to add a simple blackbox-style capture so I can get the fault context even if the device freezes during long-term operation.

Thanks again for your help.

RE: Random BLE disconnections and occasional system hang on nRF52832 using bare-metal SDK (external RTC used)

Einar Thorsrud — Mon, 05 Jan 2026 13:41:43 GMT

Hi,

You write that internal RTC is not used by the application, but it is used by the SoftDevice (which always use RTC0). Regarding the use of external RTC I do not immediately see how that could be relevant (given that it is anyway not used by the SoftDevice).

Blocking the SoftDevice for too long can be problematic so critical sections should be short, and you should not use higher interrupt priorities for the application. See Interrupt priority levels. If this cause a problem, the SoftDvice will assert. Note that there is no way to recover from a SoftDevice assert, so you need to reset after that (but should log the assert, and create a support ticket with the assert address if you need more information about it).

I do not believe this is the reason for the issue, though. Do you have logs from the nRF? The Android log you have posted indicate that the bonding data is deleted on he phone side, and in that case, the nRF will by default not accept pairing again. If this is the problem, that can be resolved by allowing re-pairing as shown in this post with the handling of the PM_EVT_CONN_SEC_CONFIG_REQ event.

If this is not the problem, it would be interesting with a sniffer trace and potentially also a log from the nRF side.