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.

[Hung Bui]

The assert location pointing me to the code inside the softdevice which checks the radio state. It expect that the radio state to be RADIO_STATE_STATE_TxIdle and assert if not. Could be a timing issue.

Could you tell more about the application ? What do you use the radio notification for ? How often do you see the issue and would you see the same issue with our example in the SDK ? (to narrow down the issue to the hardware)

[Karl]

It is a smart watch that is capable of displaying phone notifications and performs radio notification to enable a timestamp synchronisation between the device and the phone. There is not much happening in the radio notification interrupt callback - only a few flags are checked and a timestamp is calculated.

Unfortunately the issue is rare but not rare enough. It happens around every 1.5 days.

I don't think it is a hardware issue. This problem seems to just have started appearing recently, and the hardware is already released since a while. It must be some recent software change that causes this.

One of the latest changes that were introduced is that the SPI interface usage was moved from asynchronous to synchronous mode (setting handler argument to NULL for nrfx_spi_init()). I don't think this should be related but maybe it rings a bell?

I will still try to run the radio notification example from the SDK on the hardware.

[Hung Bui]

Could you please check the interrupt level of the SPI peripheral ? When using with softdevice the interrupt level should be either at level 2, 3 or above 4 (5,6,7). If it's at level 2 or 3 it should not call any softdevice function. 

Is there any chance that the blocking function of SPI was called inside a interrupt handler ?