Softdevice assertion: nRF54L15

[JordanYates]

I have observed a Softdevice assertion, built from the v3.1.0 commit. https://github.com/nrfconnect/sdk-nrfxlib/tree/v3.1.0

#define CONFIG_MPSL_LIB_DIR "nrf54l"

#define CONFIG_MPSL_LIB_FLOAT_ABI_DIR "soft-float"

#define CONFIG_BT_LL_SOFTDEVICE_MULTIROLE 1

The assertion was seen through Memfault, I believe the `file` and `line` parameters have been overwritten, but I have the backtrace through the obfuscated symbols.

[Susheel Nuguru]

Hi Jordan, 

The snapshot of backtrace seems to be from the point signal handler is being called. We need the backtrace of call just before that signal handler was called. Is there any chance that you have serial logs that can give the instruction address that did the memory access violation?

[JordanYates]

That is not a signal handler, that is the backtrace at the assertion failure.
It is an assertion failure, not a memory access violation.

[Susheel Nuguru]

Ah, sorry, missed the obvious.

We need to know the file and line to check the mapping we have internally about the assert handlers.

Is there any way you can help us reproduce the error? Could it be a stack overflow? Could you try to calibrate some thread stack sizes by increasing them from what you have by default?

[JordanYates]

I am a bit confused, the screenshot has the complete list of functions the interrupt transitions through from `mpsl_radio_isr_wrapper` to `sdc_assertion_handler`, how can the filename and line number be required to find where the assertion is?

> Is there any way you can help us reproduce the error?
Not really, the fault has only occurred once.

> Could it be a stack overflow?
In an interrupt handler? I'm not sure how that would work.

[JordanYates]

Since I am also seeing another, more common assertion, it looks like I will need to invest time in logging the filename and line number if the backtrace is somehow insufficient.

Since I don't believe there is a way to test generating an assertion, can you tell me whether the `filename` pointer points to a ROM variable or a constructed RAM value? I need to know whether I can just save the pointer and grab the string from the `.elf` file, or whether I need to save the entire string somewhere.