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]

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

[JordanYates]

That's not exactly possible when the devices are in the middle of a farm 2 hours away.
This whole process would be much easier (and more compact for remote devices) if the assertions just reported a unique 32bit ID, it's not like users can do anything with an internal file name anyway.

[Susheel Nuguru]

Please ignore the file name and give us just the line number, based on the line number we will try to map the file name internally and try to figure out what is happening. We might have some theory on why this might be happening, but we need that line number of the assert to be sure and suggest you fixes/workarounds