Seeking MPSL ASSERT 112, 2195 cause

RE: Seeking MPSL ASSERT 112, 2195 cause

Susheel Nuguru — Thu, 09 Mar 2023 19:52:10 GMT

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.

[quote user="Aeneas"]Can the VS-Code version auto-installed be rolled back ?[/quote]

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.

RE: Seeking MPSL ASSERT 112, 2195 cause

Aeneas — Thu, 09 Mar 2023 10:19:08 GMT

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

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

RE: Seeking MPSL ASSERT 112, 2195 cause

Susheel Nuguru — Thu, 09 Mar 2023 08:26:30 GMT

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

Your initial text from the description is

[quote user=""]

I am experiencing it now regularly usually directly

after servicing my first breakpoint after boot, then continuing.

[/quote]

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.

RE: Seeking MPSL ASSERT 112, 2195 cause

Aeneas — Wed, 08 Mar 2023 14:37:49 GMT

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.

RE: Seeking MPSL ASSERT 112, 2195 cause

Susheel Nuguru — Wed, 08 Mar 2023 14:31:47 GMT

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.

RE: Seeking MPSL ASSERT 112, 2195 cause

Aeneas — Wed, 08 Mar 2023 13:21:55 GMT

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.

RE: Seeking MPSL ASSERT 112, 2195 cause

Susheel Nuguru — Wed, 08 Mar 2023 13:12:15 GMT

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.

RE: Seeking MPSL ASSERT 112, 2195 cause

Aeneas — Tue, 07 Mar 2023 06:52:37 GMT

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 ?

RE: Seeking MPSL ASSERT 112, 2195 cause

Susheel Nuguru — Tue, 07 Mar 2023 06:05:45 GMT

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.

RE: Seeking MPSL ASSERT 112, 2195 cause

Aeneas — Mon, 06 Mar 2023 12:51:44 GMT

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.

RE: Seeking MPSL ASSERT 112, 2195 cause

Susheel Nuguru — Mon, 06 Mar 2023 11:33:40 GMT

We know that this ASSERT is intentionally triggered by MPSL when it finds out that its RTC0 interrupt context has been masked longer than it can allow. We have seen this assert before in different occasions and we have seen this or similar asserts when breakpoints were triggered in the application code.

I do not understand how saw that you had breakpoints working before. The only explanation I can think of is that in previous builds you were using CONFIG_BT_LL_SW_SPLIT=y which means that you were using Zephyr controller which does not have the same limitation as our Softdevice_controller on not allowing the application to mask the softdevice specific interrupts.

Can you give me your project where you have breakpoints working with CONFIG_BT_LL_SW_SPLIT=n (and CONFIG_BT_LL_SOFTDEVICE=y) in older setup and have the breakpoints working. I have tried different samples from older SDKs and could not make the breakpoint work and then continue the application from there.

There might be another issue in the VSCODE debugging extension that might have a behavioral difference from old version to new version, in anycase, I do not see how VSCODE extension can overcome the limitation of "not masking softdevice interrupts" and still make the debug experience as if it was allowed.

RE: Seeking MPSL ASSERT 112, 2195 cause

Aeneas — Mon, 06 Mar 2023 09:32:17 GMT

That sample seems to have been removed from 2.2.0 and since

it requires several available buttons and leds, it is targeted

mainly at the DKs.

As already stated, I have been using breakpoints in active BLE environments

for months with no problems.

However, this crash also occurs without breakpoints, after debug/flash

(in vs-code), simply by clicking the pause/continue button 5 times --

on that final (5th) pause, execution is looping in fatal.c .

However, the most productive thing is to look at the aftermath exception data

I have presented and state what could be causing this crash ?

I am especially interested in 2 persistent crash ingredients:

1) the line: <signal handler called> Unknown Source 0, and

2) what is the purpose of mpsl_timer0 and what does its persistent

involvement in this system crash indicate ?

Following is another iteration of this crash's exception data:

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

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)

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

RE: Seeking MPSL ASSERT 112, 2195 cause

Susheel Nuguru — Mon, 06 Mar 2023 08:46:32 GMT

I tried to put a breakpoint in peripheral_lbs example as shown below and you can see that when the breakpoint is hit and I try to continue by from here

I get this hardfault

I am using nRF Connect SDKv1.9.1 and I see this limitation still there even in the older SDK than you were using before. Remember that you can debug your application and set breakpoints without issue before enabling the bluetooth.

RE: Seeking MPSL ASSERT 112, 2195 cause

Aeneas — Fri, 03 Mar 2023 14:29:15 GMT

I have been developing and breakpoint debugging BLE code for several months

with this tool set 2.1.2 and 2.2.0 with Advertisements and Data Connection transfers

and have been using 2.2.0 for months.

This seems to be a new problem (maybe for the past week or two) in VS Code which should be investigated.

Debugging protocols like BLE with their inherent protocol timeouts occurring is commonplace --

that should not cause a debugger to fail in such a dramatic manner.

The tools seem to auto-update -- VS Code help/about gives a date that it says was "2 days ago".

How would the user transition back to what was running 2 weeks ago ?

RE: Seeking MPSL ASSERT 112, 2195 cause

Susheel Nuguru — Fri, 03 Mar 2023 12:17:03 GMT

You cannot use breakpoints to debug a BLE application when there is ongoing BLE activity. Check this thread for instance. Monitor mode debugging normally is helpful in this cases but I am not used this with Nordic Connect SDK.