NRF_FAULT_ID_SD_ASSERT every once in a while

[Karl]

Every once in a while I am experiencing the soft device error NRF_FAULT_ID_SD_ASSERT. 

In this post I saw that you may be able to provide some information on what is going wrong inside the soft device by knowing the program counter address, when this error occurs.

The PC is at 0x0001b588.

We are not using the time slot API. Our peripheral is merely connected to a master device (mobile phone). We do utilize the radio notification callback though.

My understanding of this error is that something (e.g. a debugger breakpoint) interrupts the time critical continuity of the execution of the soft device, but how can this be if the soft device is running on the highest priority interrupt?

Is there anything you can tell me based the provided PC?

Do you have any more tips on how to debug such an issue?

[Turbo J]

Karl said:

but how can this be if the soft device is running on the highest priority interrupt?

Unfortunately that is also the default priority in ARM Cortex-M.

Forgetting to configure any other NVIC interrupt priority can cause these asserts, because the softdevice fails to follow strict BT LE timings. That is why application interrupts MUST NOT use the restricted interrupt priorities.

Also you forgot to provide us with the softdevice version...

[Karl]

Also you forgot to provide us with the softdevice version

Yes of course! The Softdevice used is version S140.

There are these interrupts that were set up and they all have interrupt priority 3 or up, which as far as I understand from the description here should be OK, as it is lower priority than level 0 and 1 which are reserved for the soft device.

Interrupt	Priority
SWI1_EGU1_IRQn	APP_IRQ_PRIORITY_LOW (3)
SWI1_IRQn	3
CAL_RTC_IRQn	CAL_RTC_IRQ_Priority (3)
RTC1_IRQn	RTC1_IRQ_PRI (7)
SWI_IRQn	SWI_IRQ_PRI (7)
TIMER1_IRQn	APP_IRQ_PRIORITY_LOW (6)
GPIOTE_IRQn	NRFX_GPIOTE_CONFIG_IRQ_PRIORITY (7)

[Hung Bui]

Hi Karlo, 

Could you give the S140 version you are using ? 

It's OK to use interrupt priority at 3 and up. But the interrupt handler running at priority 3, shouldn't call any Softdevice API (for example send a notification, or advertise) because these can't run at that context level. 

[Karl]

Hung Bui said:

e interrupt handler running at priority 3, shouldn't call any Softdevice API (for example send a notification, or advertise) because these can't run at that context level. 

Thank you I will verify this.

Here are the versions in use:

• s140_nrf52_6.1.0
• NRF SDK 15.2.0

[Karl]

Karl said:

Thank you I will verify this.

I just verified - The interrupts configured with priority 3 are not executing any SoftDevice API functions. 

[Karl]

Another idea that I had to get a deeper insight is to check the NVIC->ISER register to see which interrupts had been enabled and what priority they were set to. The code to that describes the data format stored in the register was taken from NVIC_EnableIRQ in core_cm4.h

for (int8_t i = Reset_IRQn; i <= SPIM3_IRQn; i++) {

  if(NVIC->ISER[(((uint32_t)(int32_t) i) >> 5UL)] & (uint32_t)(1UL << (((uint32_t)(int32_t)i) & 0x1FUL)))
  {
    printf("Interrupt-id\t%d\tenabled\t%d\n", i, NVIC_GetPriority(i));
  } else {
    printf("Interrupt-id\t%d\n", i);
  }
  nrf_delay_ms(1);
}

From this I compiled a table based on the IRQn_Type which is defined in the nrf52840.h 

Please let me know if this type of analysis is valid and if you see it showing any hints towards the issue.