Softdevice assertion: nRF54L15

RE: Softdevice assertion: nRF54L15

Susheel Nuguru — Thu, 06 Nov 2025 09:36:23 GMT

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

RE: Softdevice assertion: nRF54L15

JordanYates — Mon, 03 Nov 2025 23:01:32 GMT

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.

RE: Softdevice assertion: nRF54L15

Susheel Nuguru — Mon, 03 Nov 2025 13:39:45 GMT

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

RE: Softdevice assertion: nRF54L15

JordanYates — Mon, 03 Nov 2025 10:10:44 GMT

> 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.

RE: Softdevice assertion: nRF54L15

Susheel Nuguru — Mon, 03 Nov 2025 07:56:42 GMT

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.

RE: Softdevice assertion: nRF54L15

JordanYates — Thu, 30 Oct 2025 07:53:26 GMT

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.

RE: Softdevice assertion: nRF54L15

JordanYates — Thu, 30 Oct 2025 07:48:21 GMT

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.

RE: Softdevice assertion: nRF54L15

Susheel Nuguru — Thu, 30 Oct 2025 07:15:51 GMT

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?

RE: Softdevice assertion: nRF54L15

JordanYates — Mon, 27 Oct 2025 07:14:42 GMT

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

RE: Softdevice assertion: nRF54L15

Susheel Nuguru — Mon, 27 Oct 2025 06:48:11 GMT

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?