Probability of HARD FAULT occurring during the BLE connection process

RE: Probability of HARD FAULT occurring during the BLE connection process

666 — Fri, 24 Apr 2026 10:40:26 GMT

Sorry for replying to you only now. The reason is that this issue is difficult to reproduce, so it took a long time. During this period, I obtained two phenomena.
The first phenomenon is that the above logs have not been added yet, but the watchdog has been turned off in order to be able to use VS code to view the scene. However, this time there were no error logs when the problem occurred. Then I connected the board to another computer's jlink and used the "Attach Debugger to Tager" function of VS code. I saw the following situation, but I cannot analyze it and am not sure if this method of capturing logs is reliable

JLinkGDBServerCL: =thread-group-added,id="i1" =cmd-param-changed,param="pagination",value="off" arch_system_halt (reason=reason@entry=31) at E:/ncs/v3.1.0/zephyr/kernel/fatal.c:30 30 for (;;) { Program received signal SIGTRAP, Trace/breakpoint trap. arch_system_halt (reason=reason@entry=31) at E:/ncs/v3.1.0/zephyr/kernel/fatal.c:30 30 for (;;) {

The second phenomenon is that the above log was added to the main, but the watchdog was still turned off, but the device still restarted without any error logs. However, I saw that the reason for the restart was Reset from CPU lockout detected.
Can you help me explain the above phenomenon, or do you have any suggestions? I have no direction left.
Looking forward to your reply!

RE: Probability of HARD FAULT occurring during the BLE connection process

Susheel Nuguru — Fri, 10 Apr 2026 13:33:04 GMT

I do not think using such a low priority for TWIM transactions directly causes the MPSL assert. I think the hardfault logs are bit too vague/generic to describe the problem.

If we suspect that this in fact is an MPSL error, then try to enable CONFIG_MPSL_ASSERT_HANDLER=y in your prj.conf and implement your mpsl assert handler something like below

#include <mpsl/mpsl_assert.h>

void mpsl_assert_handle(char *file, uint32_t line)
{
	LOG_ERR("MPSL ASSERT: %s, %u", file ? file : "<null>", line);
	k_panic();
}

This is also explained in NCS/nrf/doc/nrf/libraries/mpsl/mpsl_assert.rst

The Multiprotocol Service Layer assert library makes it possible to add a custom assert handler to the :ref:`nrfxlib:mpsl` library.
You can then use this assert handler to print custom error messages or log assert information.

:kconfig:option:`CONFIG_MPSL_ASSERT_HANDLER` enables the custom assert handler.
If enabled, the application must provide the definition of :c:func:`mpsl_assert_handle`.
The :c:func:`mpsl_assert_handle` function is invoked whenever the MPSL code encounters an unrecoverable error.

API documentation
*****************

| Header file: :file:`include/mpsl/mpsl_assert.h`

RE: Probability of HARD FAULT occurring during the BLE connection process

666 — Thu, 09 Apr 2026 04:05:48 GMT

We are using nrfx_twim_init(...), where the interrupt priority is NRFX_TWIM_DEFAULT_CONFIG_IRQ_PRIORITY(7). Is it possible that this priority is too high and may affect MPSL init ?

Very urgent, looking forward to your advice！

RE: Probability of HARD FAULT occurring during the BLE connection process

666 — Tue, 07 Apr 2026 01:08:36 GMT

Because the reading function of I2C cannot be changed, I would like to solve this problem from other aspects. Do you have any good suggestions?

RE: Probability of HARD FAULT occurring during the BLE connection process

666 — Thu, 02 Apr 2026 01:12:03 GMT

Random and with a low probability.When will MPSL init ? The above phenomenon occurs during the communication process after Bluetooth connection.Why does I2C read affect it? Is it due to priority reasons

RE: Probability of HARD FAULT occurring during the BLE connection process

Simonr — Tue, 31 Mar 2026 05:36:53 GMT

When does the phenomena 1 occur versus phenomena 2? Or is it seemingly random that either of these occur. I think the MPSL init assert can be caused by the I2C reading data very often when the MPSL is trying to init.

Best regards,

Simon