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]

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.

[Susheel Nuguru]

This latest stack trace that you have provided might be enough for us to narrow this to few asserts in the code. Will come back to you with some more useful info.

-------------
EDIT
------------
Turns out that we still need the file and line number given to the sdc_assertion_handler to narrow down which assert causes this. So please try to get that info and post it here.

Also, can you tell me more about what your application was doing so that we can get more context and map the path on how your application execution ended up here.

[JordanYates]

> Turns out that we still need the file and line number given to the sdc_assertion_handler to narrow down which assert causes this. So please try to get that info and post it here.

I still need to know whether the pointer is sufficient and can be mapped back to the file name or whether I need to store the whole string? There is no way I know of to manually trigger an assertion to test this myself.

> Also, can you tell me more about what your application was doing so that we can get more context and map the path on how your application execution ended up here.

Scanning on Bluetooth advertising, extended advertising, connecting to remote devices, sending GATT packets, receiving GATT packets. It does most things Bluetooth can, its not going to narrow it down at all.

[Susheel Nuguru]

The pointer points to a null terminated string in RAM. So should be able to see it in the debugger memory view