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]

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