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)

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

[Susheel Nuguru]

Just setting the breakpoint and not hitting hit makes the application assert is something I have not seen before. Could be vscode extension issue.

Setting the breakpoint and hitting it and continuing after that causes assert is understandable which I have explained in my previous answers.

MPSL assert 112 2197 happening abruptly,  we have seen this before when there are efficiency issues with your crystal oscillators and/or your external load capacitor not matching our recommendations.

[Aeneas]

I have not seen (or mentioned) an Assert 112, 2197 .  

And I have yet to hear a clear actionable description of the cause

of 112, 2195, or a workaround for it.

[Susheel Nuguru]

It was a typo writing MPSL assert 112 2197, I meant MPSL assert 112 2195.

Your initial text from the description is

I am experiencing it now regularly usually directly

after servicing my first breakpoint after boot, then continuing.

That particular issue of servicing your breakpoint and continuing will not work on our latest SDKs (Neither with softdevice controller not with Zephyr controller. It used to work on zephyr controller few releases ago, which release it stopped working exactly, I do not know, but this is intentional behavior that it stopped working).

If the above issue happens without a breakpoint in picture, then it points to your hfclk crystal accuracy.

On your other issues with not able to set the breakpoint at all, I requested you to test this on Ozone. If you can reproduce this on Ozone, then we do not need to focus on Vscode issues and focus on hardware/firmware workarounds. Compile the code with debug options and no code optimizations. 

[Aeneas]

Never heard of Ozone.  How would you compare it to VS-Code ?

Can the VS-Code version auto-installed be rolled back ?

[Susheel Nuguru]

Ozone is just a debugger and not a complete IDE in itself.I was suggesting you to try using it and see if setting breakpoints works with it. So that we can know if this is a vscode issue or something else.

Aeneas said:

Can the VS-Code version auto-installed be rolled back ?

This is something that you can find in vscode sites. For example if you want to revert one particular extension, then you can do as mentioned here in their site.