Seeking MPSL ASSERT 112, 2195 cause

[Aeneas]

Another  MPSL ASSERT 112, 2195  instance.

I am experiencing it now regularly usually directly

after servicing my first breakpoint after boot, then continuing.

The next mouse-click of pause after 1st continue, and execution is looping in fatal.c .

(arch_system_halt).

What is causing 112, 2195 ?

(VS-Code/Segger Base/custom pcb nrf52840) // nrf52840 DK BLE Standalone// nrf52840 DK Sniffer//

======================================

(VS-Code/Help/About)

Version: 1.76.0 (user setup)
Commit: 92da9481c0904c6adfe372c12da3b7748d74bdcb
Date: 2023-03-01T10:22:44.506Z
Electron: 19.1.11
Chromium: 102.0.5005.196
Node.js: 16.14.2
V8: 10.2.154.26-electron.0
OS: Windows_NT x64 10.0.22621
Sandboxed: Yes

=======================================

[00:00:30.605,316] <err> mpsl_init: MPSL ASSERT: 112, 2195
[00:00:30.605,346] <err> os: ***** HARD FAULT *****
[00:00:30.605,346] <err> os: Fault escalation (see below)
[00:00:30.605,377] <err> os: ARCH_EXCEPT with reason 3

[00:00:30.605,407] <err> os: r0/a1: 0x00000003 r1/a2: 0x20002c68 r2/a3: 0x20002c68
[00:00:30.605,407] <err> os: r3/a4: 0x00045a9f r12/ip: 0x00000000 r14/lr: 0x000409fd
[00:00:30.605,438] <err> os: xpsr: 0x61000018
[00:00:30.605,438] <err> os: Faulting instruction address (r15/pc): 0x0003a9f4
[00:00:30.605,499] <err> os: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
[00:00:30.605,499] <err> os: Fault during interrupt handling

[00:00:30.605,560] <err> os: Current thread: 0x20002c68 (idle)
[00:00:30.979,431] <err> os: Halting system

==========================================

arch_system_halt(unsigned int reason) (c:\nordicsemi\v2.2.0\zephyr\kernel\fatal.c:32)
k_sys_fatal_error_handler(unsigned int reason, const z_arch_esf_t * esf) (c:\nordicsemi\v2.2.0\zephyr\kernel\fatal.c:46)
z_fatal_error(unsigned int reason, const z_arch_esf_t * esf) (c:\nordicsemi\v2.2.0\zephyr\kernel\fatal.c:131)
z_arm_fatal_error(unsigned int reason, const z_arch_esf_t * esf) (c:\nordicsemi\v2.2.0\zephyr\arch\arm\core\aarch32\fatal.c:63)
z_arm_fault(uint32_t msp, uint32_t psp, uint32_t exc_return, _callee_saved_t * callee_regs) (c:\nordicsemi\v2.2.0\zephyr\arch\arm\core\aarch32\cortex_m\fault.c:1097)
z_arm_usage_fault() (c:\nordicsemi\v2.2.0\zephyr\arch\arm\core\aarch32\cortex_m\fault_s.S:102)
<signal handler called> (Unknown Source:0)
m_assert_handler(const char * const file, const uint32_t line) (c:\nordicsemi\v2.2.0\nrf\subsys\mpsl\init\mpsl_init.c:176)
sym_S2UAPMFVIQXDUOA6CV7GJMB33TYHEUH5D6LHO5Q (Unknown Source:0)
sym_J5F7QGRFPKMLWRNSXZXS5YI7BM4DUTISCOASCOA (Unknown Source:0)
MPSL_IRQ_TIMER0_Handler (Unknown Source:0)
mpsl_timer0_isr_wrapper_body() (c:\nordicsemi\v2.2.0\nrf\subsys\mpsl\init\mpsl_init.c:130)
mpsl_timer0_isr_wrapper() (c:\nordicsemi\v2.2.0\nrf\subsys\mpsl\init\mpsl_init.c:128)
<signal handler called> (Unknown Source:0)
arch_cpu_idle() (c:\nordicsemi\v2.2.0\zephyr\arch\arm\core\aarch32\cpu_idle.S:108)
k_cpu_idle() (c:\nordicsemi\v2.2.0\zephyr\include\zephyr\kernel.h:5627)
idle(void * unused1, void * unused2, void * unused3) (c:\nordicsemi\v2.2.0\zephyr\kernel\idle.c:83)
z_thread_entry(k_thread_entry_t entry, void * p1, void * p2, void * p3) (c:\nordicsemi\v2.2.0\zephyr\lib\os\thread_entry.c:36)

==================================================================

[Aeneas]

So, would that length of masking of interrupts indicate that

too much work is scheduled for the active threads ?

Would it be a correct assumption that RTC0 drives the 

1 KHz clock for the thread timing (time (ms) since boot, etc) ?

On breakpoints, the problem I have had, which even exists in samples

which have no bluetooth at all, is that there are enormous sequences of 

C statements which do not allow a breakpoint when clicked on.

But there is never a situation where no breakpoints can be set at all.

In fact, this issue of failure in vs-code to be able to place a breakpoint

on a particular line is one of the most serious failings in vs-code --

and again, this occurs even in sensor samples which have no bluetooth at all.

I just tried typing your CONFIG_BT_LL_SW_SPLIT=y into my prj.conf and hovering over it,

and it does not appear to have any prior designation, Y or N.

I have not seen that set in any of the samples I have tried.

[Susheel Nuguru]

Mark,

There seems to be a confusion in few things here. Let me try to break it down.

Ability to set breakpoints:
This is capability of the debugger and compiler. When you have disable the CONFIG_DEBUG_OPTIMIZATIONS in your proj.conf and having set the debug options like below in vscode.

When debugger running:
Ability to hit breakpoint and continue after that:
1) With CONFIG_BT_LL_SOFTDEVICE=y (default now with our SDK)
This was never working after you enable Nordic BLE stack. Not with our older baremetal solutions and not with newer zephyr RTOS based solution. We always had a limitation that application does not halt CPU or mask the RTC0 interrupt more than few us. There are lots of explanation on this in the devzone. There has never been a confusion that without Monitor Mode Debugging (MMD) you cannot hit a breakpoint, hit the continue button and expect that the debugging will work without assertion. This assertion is by design from the softdevice architecture.

2) With CONFIG_BT_LL_SW_SPLIT=y
When using this option, hitting breakpoint and continuing after that was working until Zephyr controller also added similar limitation in this commit. These changes were pulled into our nRF Connect SDK most likely in the release after v2.1.3. So this means that after that release both Zephyr Controller and Softdevice Controller will ASSERT if the prepare signal is found to be delayed (only hapens when CPU is halted or the context of prepare is being masked)

In your case, when you say that it was working, most likely you used Zephyr controller ( CONFIG_BT_LL_SW_SPLIT=y) before this change. And now with later revisions than v2.1.3, it does not matter which controller you use, you cannot have your breakpoint hit (leading to CPU hlt) and continue to debug without an intentional ASSERT. 

I hope this is clear now.

[Aeneas]

This breakpoint problem in my experience has worsened dramatically over the past 2 weeks.

I have been using 2.2.0 for the past 2 months, so I do not believe that is the recent

change responsible.

On the other hand, VS-Code Help/About seems to report updates occurring automatically.

How much does the VS-Code shell have to do with this debugger breakpoint problem ?

I cannot stress enough that:

the highest priority for a debugger is to Set Breakpoints.

Nothing is more important than that.

I do not receive the impression here that that is believed by the VS-Code developers.

If all the user wants to do is launch their code, they can do that without an expensive

debugger like Segger.

There seem to be some nice features added to the debugger, like

MPU protection of regions like the stack which deserve praise,

but nothing is more important than the user being able to set and service breakpoints,

ll_softdevice or ll_sw_split,  on every line in his program and included kernel.

VS-Code Debugger developers who are having difficulties with breakpoints should discuss

those problems in the general vs-code shell design publicly, here on this forum.

How would a user backtrack to previous versions of VS-Code ?

And how is the auto-update feature in VS-Code disabled ?

[Susheel Nuguru]

I thought this was an issue with breakpoints causing asserts but if this is the matter of not being able to use breakpoint feature properly then it is a different issue. Are you able to use some other debugger (for example Ozone) and see no issues? If that is a yes, then what you are saying needs to be reported to the VSCODE extension team and hopefully they will fix it soon.

[Aeneas]

Currently (past week or so), almost every time I click to set a breakpoint, I receive a 112, 2195 Assert.

However, there has been an ongoing issue for all the months I have used this platform

of not being able to set breakpoints over extended stretches of code in multiple code files --

red circle does not appear, breakpoint not activated.

Thus, I assume there is a pervasive problem in the breakpoint area of this code.