ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0

[Rajiv Verma]

In Lesson-3 Ex-2 for the BLE Fundamentals course, the steps for setting preferred PHY (steps 7 thru 9) is causing fault on my nRF52840-DK board.

Log messages are as follows:

*** Booting nRF Connect SDK v3.1.0-6c6e5b32496e ***
*** Using Zephyr OS v4.1.99-1612683d4010 ***
[00:00:00.000,335] <inf> Lesson3_Exercise2: Starting Lesson 3 - Exercise 2

[00:00:00.000,732] <inf> bt_sdc_hci_driver: SoftDevice Controller build revision: 
                                            fc de 41 eb a2 d1 42 24  00 b5 f8 57 9f ac 9d 9e |..A...B$ ...W....
                                            aa c9 b4 34                                      |...4             
[00:00:00.003,112] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:00.003,143] <inf> bt_hci_core: HW Variant: nRF52x (0x0002)
[00:00:00.003,173] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 252.16862 Build 1121034987
[00:00:00.004,058] <inf> bt_hci_core: HCI transport: SDC
[00:00:00.004,211] <inf> bt_hci_core: Identity: E5:4F:6C:1F:37:4C (random)
[00:00:00.004,241] <inf> bt_hci_core: HCI: version 6.1 (0x0f) revision 0x1069, manufacturer 0x0059
[00:00:00.004,272] <inf> bt_hci_core: LMP: version 6.1 (0x0f) subver 0x1069
[00:00:00.004,272] <inf> Lesson3_Exercise2: Bluetooth initialized
[00:00:00.005,187] <inf> Lesson3_Exercise2: Advertising successfully started
[00:00:05.575,592] <inf> Lesson3_Exercise2: Connected
[00:00:05.575,622] <inf> Lesson3_Exercise2: Connection parameters: interval 30.00 ms, latency 0 intervals,              timeout 720 ms
ASSERTION FAIL [err == 0] @ WEST_TOPDIR/zephyr/subsys/bluetooth/host/hci_core.c:504
        Controller unresponsive, command opcode 0x2032 timeout with err -11
[00:00:15.575,805] <err> os: r0/a1:  0x00000003  r1/a2:  0x00000000  r2/a3:  0x00000002
[00:00:15.575,836] <err> os: r3/a4:  0x00000003 r12/ip:  0x00000010 r14/lr:  0x00012907
[00:00:15.575,836] <err> os:  xpsr:  0x01000000
[00:00:15.575,836] <err> os: s[ 0]:  0x20004850  s[ 1]:  0x20004850  s[ 2]:  0x00000000  s[ 3]:  0x00000001
[00:00:15.575,866] <err> os: s[ 4]:  0x20004860  s[ 5]:  0x20004860  s[ 6]:  0x00000002  s[ 7]:  0x00000000
[00:00:15.575,866] <err> os: s[ 8]:  0x200048a8  s[ 9]:  0x20001c20  s[10]:  0x200048a8  s[11]:  0x20004934
[00:00:15.575,897] <err> os: s[12]:  0x00000000  s[13]:  0x00000001  s[14]:  0x20000330  s[15]:  0x00020bb3
[00:00:15.575,897] <err> os: fpscr:  0x00000000
[00:00:15.575,927] <err> os: Faulting instruction address (r15/pc): 0x00012916
[00:00:15.575,958] <err> os: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
[00:00:15.575,988] <err> os: Current thread: 0x20001b38 (unknown)
[00:00:15.681,213] <err> os: Halting system

Development Setup:

nRF Connect SDK v3.1.0

nRF Connect SDK Toolchain v3.1.0

Board/Target: nrf52840dk/nrf52840

Environment:

Visual Studio Code

Version: 1.103.2 (user setup)
Commit: 6f17636121051a53c88d3e605c491d22af2ba755
Date: 2025-08-20T16:45:34.255Z
Electron: 37.2.3
ElectronBuildId: 12035395
Chromium: 138.0.7204.100
Node.js: 22.17.0
V8: 13.8.500258-electron.0
OS: Windows_NT x64 10.0.26100

l3_e2.zip

[Rajiv Verma]

Update:

The issue appears to be happening when update PHY mode (to 2M) is attempted in the `on_connect()` callback. I wonder if doing this in a callback is the issue here because the `bt_conn_le_phy_update()` eventually results in call to `k_sem_take(&sync_sem, HCI_CMD_TIMEOUT);` in `bt_hci_cmd_send_sync()` (hci_core.c) thus blocking the callback. Depending on the context of the callbacks this may be disallowed (at least in the SDK v3.1.0) since the example obviously worked earlier.

[Rajiv Verma]

Update:

It does appear to be an issue of calling the update PHY in the callback. If I move this to the main() then the crash does not happen. This is what I did in the main()'s while loop:

	for (;;) {
		if (connected && !phy_updated) { //added two bool status in appropriate callbacks
			update_phy(my_conn);
		}
		dk_set_led(RUN_STATUS_LED, (++blink_status) % 2);
		k_sleep(K_MSEC(RUN_LED_BLINK_INTERVAL));
	}

[Edvin]

Hello,

Thank you for the feedback. We are trying to maintain the samples in DevAcademy before major breaking changes, but unfortunately, we are not able to verify everything before every release. I will look into it and implement a workaround, and adjust the wording accordingly. 

I your workaround works, then I don't see any issues with it. But if you want to not clutter up your main() loop, I think a neater solution is to use a workqueue for this. 

Pretty much as described in the documentation of timers:

https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/kernel/services/timing/timers.html#using_a_timer_expiry_function

But replace the timer and timeout handler with the connection callback.

Best regards,

Edvin

[Edvin]

Hello,

I just wanted to let you know that I found the reason why the issue didn't reproduce in the devacademy sample, but it did in yours was that you were missing a delay added in step 7.2. I agree that it is not clearly explained that you should add it. At least not when just working through the steps. It is mentioned later in step 13.5.

However, it shouldn't be needed. It was in fact an issue / a bug in the Bluetooth host, and I have added a workaround in the github repository now. But you can also add it to your own project by simply adding this line at the end of your prj.conf:

CONFIG_BT_BUF_CMD_TX_COUNT=2

It will probably be fixed in a future release of NCS.

Best regards,

Edvin