SOFTDEVICE: ASSERTION FAILED PC=0x00014CBC

RE: SOFTDEVICE: ASSERTION FAILED PC=0x00014CBC

Sigurd — Tue, 02 Sep 2025 12:09:24 GMT

It's because the address is in the SoftDevice, not in your application.

Are you using a LF crystal on your board? Maybe the ppm for it is configured wrong.

Try e.g. setting

NRF_SDH_CLOCK_LF_ACCURACY to 1 (500ppm) in sdk_config.h, and see if that helps.

RE: SOFTDEVICE: ASSERTION FAILED PC=0x00014CBC

Chaoyue Ying — Tue, 02 Sep 2025 00:17:02 GMT

I'm using a custom board.

I attempted to convert the PC address into the file name and line number using addr2line, and the result was like this:

Regarding this output, the relevant information I have obtained is as follows

If the output is ??:0, possible reasons include: 
Invalid address
The executable file does not contain debugging information
The input file type is incorrect (it is necessary to distinguish between the executable file and the relocatable object)

RE: SOFTDEVICE: ASSERTION FAILED PC=0x00014CBC

Sigurd — Mon, 01 Sep 2025 10:54:49 GMT

At least the PC(program counter) value can with addr2line translate it into file names and line numbers. The PC value you see in the log, points to the location of the assert inside the SoftDevice.

Are you using a DK or a custom board?

RE: SOFTDEVICE: ASSERTION FAILED PC=0x00014CBC

Chaoyue Ying — Mon, 01 Sep 2025 09:05:02 GMT

Hi,

What I mean is whether it is possible to use methods like register pointers to determine which part is experiencing priority blocking or Stony Brook timeout.It should not be caused by disabling the global interrupt.I attempted to output p_file_name and line_num, but the result was garbled characters. I was unable to pinpoint the exact location of the error.

RE: SOFTDEVICE: ASSERTION FAILED PC=0x00014CBC

Sigurd — Mon, 01 Sep 2025 07:22:25 GMT

Hi!

[quote user=""]I will encounter SOFTDEVICE: ASSERTION FAILED from time to time, like this:[/quote][quote user="Chaoyue Ying"]how can I determine the location where the assert occurred?[/quote]

The assert happened in the SoftDevice. I have checked the SoftDevice location, and this assert indicates that the SoftDevice was unable to process a BLE event in time. See my previous answer for more information.

RE: SOFTDEVICE: ASSERTION FAILED PC=0x00014CBC

Chaoyue Ying — Mon, 01 Sep 2025 03:21:34 GMT

Hi,

If this is a software issue, how can I determine the location where the assert occurred?

RE: SOFTDEVICE: ASSERTION FAILED PC=0x00014CBC

Sigurd — Fri, 29 Aug 2025 12:18:27 GMT

Hi!

I assume then, that you are using s132_nrf52_7.0.1

The assert indicates that the SoftDevice was unable to process a BLE event in time. The BLE protocol have timing requirements, and when they are not meet the SoftDevice will assert. There could be several reasons why the SoftDevice did not process these events in time:

You are somehow blocking the SoftDevice in a higher priority interrupt/task/thread, and therefore not giving the SoftDevice enough time to process the BLE events. It could potentially also happen when debugging with breakpoints.
The application disabled interrupt globally at an unfortunate time
You are using the Timeslot API, and not ending the timeslot in time, i.e. you spent too much time in the timeslot.
If this is a custom board, it could be some HW issues with the crystal(s) you are using.

RE: SOFTDEVICE: ASSERTION FAILED PC=0x00014CBC

Chaoyue Ying — Fri, 29 Aug 2025 01:48:29 GMT

Hi,

The version is nRF5_SDK_17.0.0_9d13099

RE: SOFTDEVICE: ASSERTION FAILED PC=0x00014CBC

Sigurd — Thu, 28 Aug 2025 10:27:31 GMT

Hi!

What variant and version of the SoftDevice are you using?