Issue with softdevice crashing with error 0

[Loden]

I'm encountering an issue where the softdevice crashes with only a couple of timers running and a main loop that feeds the watchdog. If I enable more of the code I've written, the device I'm using starts crashing more often, sooner, and less predictably. Most of the times I'm unable to catch the issue, since the sd writes 0xdeadbeef into all registers. I've managed to catch one error now with the following information:

(nrf52832, sdk version: ?, SoftDevice S132 v6.0.0)

id: NRF_FAULT_ID_SD_ASSERT

pc: 0x00012a42

info: 0

The code usually boots fine past the initialization of the softdevice, but after that it's basically a matter of time and a seemingly random moment at which it crashes.

Edit: After re-enabling amounts of the code that should be running, I get the following PC values for crashes:
- 0x000008e8

- 0x0002f7f6

It also sometimes just reboots straight away without even going through the app_error_fault_handler I've declared. I understand this makes the issue less clear, but it might also shed some light. Who knows.

[Kenneth]

Make sure you check out:
https://infocenter.nordicsemi.com/topic/sds_s132/SDS/s1xx/processor_avail_interrupt_latency/exception_mgmt_sd.html 

The asserts you see are typically due to application is preventing the timining-critical handling in the softdevice, so the application interrupts must be lower interrupt priority than the softdevice and the application can't disable interrupts.

Best regards,
Kenneth

[Loden]

Thanks for the response Kenneth. I already checked the interrupt priorities before asking this question, but I checked them again. All app and peripheral interrupt priorities are set to 7, except for one which is at 6 and the app ble observer which is at 3. All of this is defined in the sdk_config.h and the defined values are the ones used, no raw numbers in config structs as far as I can tell.

The only references to __disable_irq() or I can find are in error handlers that get called when the softdevice asserts. There is no usage of  app_util_critical_region_enter or app_util_disable_irq. The issues I'm encountering seem to change with every build and memory layout. At the moment I have to have one of the app timers disabled due to it crashing the softdevice, but with previous builds this was not necessary.

Are there other ways in which the application could be in the way of the softdevice and is there a way in which I can find out which part of the application was blocking the softdevice at the time of the failed assert?

[Kenneth]

Add logging to the app_timers (and other callback handlers or interrupts) when entering and leaving the handler(s) to try to narrow down which can be the problematic one.

Kenneth