Bluetooth debug causing hard fault / kernel error / ARCH_EXCEPT

I recently flashed my nrf52840dk with the mesh light example and was trying to debug some application key issues I was facing. When I try to step through the code with a debugger, I get the following errors/panic/reset, am I doing something wrong? Is there something special you have to do to debug a bluetooth application?

[00:00:00.007,110] <inf> fs_nvs: nvs_mount: 8 Sectors of 4096 bytes
[00:00:00.007,110] <inf> fs_nvs: nvs_mount: alloc wra: 0, e10
[00:00:00.007,141] <inf> fs_nvs: nvs_mount: data wra: 0, 228
[00:00:00.007,415] <inf> bt_sdc_hci_driver: hci_driver_open: SoftDevice Controller build revision: 
                                            c5 93 ba a9 14 4d 8d 05  30 4e 9b 92 d7 71 1e e8 |.....M.. 0N...q..
                                            aa 02 50 3c                                      |..P<             
[00:00:00.010,925] <inf> bt_hci_core: hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)
[00:00:00.010,986] <inf> bt_hci_core: hci_vs_init: HW Variant: nRF52x (0x0002)
[00:00:00.011,016] <inf> bt_hci_core: hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 197.47763 Build 2370639017
[00:00:00.011,413] <inf> bt_hci_core: bt_init: No ID address. App must call [00:00:21.570,953] <err> mpsl_init: m_assert_handler: MPSL ASSERT: 108, 812
[00:00:21.570,983] <err> os: hard_fault: ***** HARD FAULT *****
[00:00:21.571,014] <err> os: hard_fault:   Fault escalation (see below)
[00:00:21.571,014] <err> os: hard_fault: ARCH_EXCEPT with reason 3

[00:00:21.571,044] <err> os: esf_dump: r0/a1:  0x00000003  r1/a2:  0x20003d58  r2/a3:  0x20003d58
[00:00:21.571,075] <err> os: esf_dump: r3/a4:  0x20006d70 r12/ip:  0x200043c8 r14/lr:  0x00040155
[00:00:21.571,075] <err> os: esf_dump:  xpsr:  0x41000011
[00:00:21.571,105] <err> os: esf_dump: Faulting instruction address (r15/pc): 0x0003be54
[00:00:21.571,136] <err> os: z_fatal_error: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
[00:00:21.571,166] <err> os: z_fatal_error: Fault during interrupt handling

[00:00:21.571,228] <err> os: z_fatal_error: Current thread: 0x20003d58 (unknown)
[00:00:21.995,666] <err> fatal_error: k_sys_fatal_error_handler: Resetting system
*** Booting nRF Connect SDK v2.5.0 ***
Initializing...
[00:00:00.007,049] <inf> fs_nvs: nvs_mount: 8 Sectors of 4096 bytes
[00:00:00.007,080] <inf> fs_nvs: nvs_mount: alloc wra: 0, e00
[00:00:00.007,080] <inf> fs_nvs: nvs_mount: data wra: 0, 248
[00:00:00.007,354] <inf> bt_sdc_hci_driver: hci_driver_open: SoftDevice Controller build revision: 
                                            c5 93 ba a9 14 4d 8d 05  30 4e 9b 92 d7 71 1e e8 |.....M.. 0N...q..
                                            aa 02 50 3c                                      |..P<             
[00:00:00.010,894] <inf> bt_hci_core: hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)
[00:00:00.010,925] <inf> bt_hci_core: hci_vs_init: HW Variant: nRF52x (0x0002)
[00:00:00.010,955] <inf> bt_hci_core: hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 197.47763 Build 2370639017
[00:00:00.011,383] <inf> bt_hci_core: bt_init: No ID address. App must call settings_load()
Bluetooth initialized
[00:00:00.281,555] <inf> bt_hci_core: bt_dev_show_info: Identity: FA:D3:46:9B:4F:AC (random)
[00:00:00.281,585] <inf> bt_hci_core: bt_dev_show_info: HCI: version 5.4 (0x0d) revision 0x1102, manufacturer 0x0059
[00:00:00.281,616] <inf> bt_hci_core: bt_dev_show_info: LMP: version 5.4 (0x0d) subver 0x1102
[00:00:00.291,229] <err> app: set_lightness: set_lightness: 0
[00:00:00.291,259] <err> app: set_lightness: set_lightness: 0
[00:00:00.291,290] <err> app: set_lightness: set_lightness: 0
[00:00:00.291,351] <err> app: set_lightness: set_lightness: 0
Mesh initialized
[00:00:05.720,245] <wrn> bt_l2cap: bt_l2cap_recv: Ignoring data for unknown channel ID 0x003a

Parents Reply Children
  • If the CPU if prevented from handling the BLE events at the expected time, the stack will assert.

    You can use SEGGER Monitor Mode debugging to mitigate this limitation.

      , thanks so much! This is precisely what I was wondering.... Is there anyway to set this up with the nRF VSCode Extension Debugging? Or do I need to create a custom launch.json of some sort to enable the monitor mode debugging? I ask because I have a couple people contributing to this and the custom configs (e.g. here) seem rather fragile in comparison to the extension debugger which works off the west config/repos

  • Hi,

    This page describes how to enable debug monitor with VS Code. Are you asking if this can be automated in some way when you start debugging, or is it sufficient to call the command when you start a debug session?

    Best regards,
    Jørgen

  • Ahhh thanks, so just pasting this inside the debug console once the configs are set?

    -exec monitorexec SetMonModeDebug=1

    I guess I was wondering if there was some setting inside the extension for it that enabled it on begin debug, but I think this is ok too.

    maybe in this case it would make sense to have a launch.json that launches the nRF debugger and does a pre build task with a custom config setting the options mentioned in your link?

    thanks so much!

  • parksj10 said:

    Ahhh thanks, so just pasting this inside the debug console once the configs are set?

    -exec monitorexec SetMonModeDebug=1

    Yes, exactly.

    parksj10 said:
    I guess I was wondering if there was some setting inside the extension for it that enabled it on begin debug, but I think this is ok too.

    No, as far as I know, there is no support for this in the extension at this point (Support for this feature was recently added in nRF Connect SDK v2.4.0).

    parksj10 said:
    maybe in this case it would make sense to have a launch.json that launches the nRF debugger and does a pre build task with a custom config setting the options mentioned in your link?

    I don't have much experience with customizing VS Code, but if it is possible to create a launcher that starts nRF Debugger and executes the command in the debug window, this should work also.

Related