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

[Sigurd]

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.