SOFTDEVICE: ASSERTION FAILED PC=0x00014CBC

[Chaoyue Ying]

I am currently debugging the nrf52832 project developed using the nrf5SDK.

I will encounter SOFTDEVICE: ASSERTION FAILED from time to time, like this:

I don't have a reliable method to reproduce this problem consistently.

By using the disassembly window of Keil, it seems that this problem occurs when the interrupt is triggered.

But I don't understand why this issue was triggered.

[Sigurd]

Hi!

What variant and version of the SoftDevice are you using?

[Chaoyue Ying]

Hi,

The version is nRF5_SDK_17.0.0_9d13099

[Sigurd]

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.

[Chaoyue Ying]

Hi,

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

[Sigurd]

Hi!

I will encounter SOFTDEVICE: ASSERTION FAILED from time to time, like this:

Chaoyue Ying said:

how can I determine the location where the assert occurred?

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.

[Chaoyue Ying]

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.

[Sigurd]

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?

[Chaoyue Ying]

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)