This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Pausing and continuing debug session makes hardfault after moving sample code to thread context

I am trying to develop an application based on peripheral_hids_mouse.

As part of making the application more modular and expandable, I am moving the the example's functionality into a thread context. I was surprised to see that I would get hardfaults after hitting a breakpoint. I then discovered that merely pausing and resuming the debug session would hardfault!

I have done multithreaded development before, but am new to the zephyr/nordic/vscode ecosystem.

Advice for how to debug this or why it is occurring would be appreciated! Slight smile

The error I see is:

E: MPSL ASSERT: 112, 2134
E: ***** HARD FAULT *****
E: Fault escalation (see below)
E: ARCH_EXCEPT with reason 3

E: r0/a1: 0x00000003 r1/a2: 0x00000000 r2/a3: 0x00000000
E: r3/a4: 0x20008316 r12/ip: 0x00000000 r14/lr: 0x00023367
E: xpsr: 0x61000018
E: Faulting instruction address (r15/pc): 0x00023372
E: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
E: Fault during interrupt handling

E: Current thread: 0x200034c0 (sysworkq)

The minimal example is the raw peripheral_hids_mouse example, only main() the contents of main are moved into a thread.

int main(void)
	return 0;

int bt_thread(void *, void *, void *)
	int err;

	printk("Starting Bluetooth Peripheral HIDS mouse example\n");

		err = bt_conn_auth_cb_register(&conn_auth_callbacks);
		if (err) {
			printk("Failed to register authorization callbacks.\n");
			return 0;

		err = bt_conn_auth_info_cb_register(&conn_auth_info_callbacks);
		if (err) {
			printk("Failed to register authorization info callbacks.\n");
			return 0;

	/* DIS initialized at system boot with SYS_INIT macro. */

	err = bt_enable(NULL);
	if (err) {
		printk("Bluetooth init failed (err %d)\n", err);
		return 0;

	printk("Bluetooth initialized\n");

	k_work_init(&hids_work, mouse_handler);
	k_work_init(&adv_work, advertising_process);
		k_work_init(&pairing_work, pairing_process);




	while (1) {
		/* Battery level simulation */

#define BT_STACK_SIZE 2048

                bt_thread, NULL, NULL, NULL,
                BT_THREAD_PRIORITY, 0, 0);

  • Hi,

    This is expected as halting the CPU will break some of the real time requirements of the Zephyr stack. You need to reset the CPU between each time it's halted/paused,



  • It seems less to do with zephyr and more to do with bluetooth?

    From another thread after more research

    "Bluetooth requires hard real-time timing intervals to be respected. If they are not, there are guards in the code that will trigger a kernel oops in order to warn the developer that something was done in the background that delayed the ISR execution beyond what is admissible as per the Bluetooth specification. This is important because in some cases the application might be disabling interrupts for too long, and this needs to be communicated to the user somehow (a kernel oops)."

  • Yeah, more specifically the Bluetooth implementation in Zephyr Slight smile