SoftDevice Controller ASSERT

[henninjw]

Hello,

I am experiencing a SoftDevice Controller ASSERT: 62, 1846.  I am using a nrf52832 acting as a peripheral and nRF Connect SDK v1.9.1. This assert happens when large number of packets are being transmitted/received. Other similar tickets(here and here) reference interrupt priority and interrupt disabling, however I only have one other interrupt of priority 7 in my application, and I am not knowingly ever disabling interrupts. Any help on how to decipher what this assert number means would be helpful. Thanks!

[00:01:13.078,338] <err> sdc_hci_driver: SoftDevice Controller ASSERT: 62, 1846
[00:01:13.078,338] <err> os: ***** HARD FAULT *****
[00:01:13.078,369] <err> os:   Fault escalation (see below)
[00:01:13.078,369] <err> os: ARCH_EXCEPT with reason 3

[00:01:13.078,369] <err> os: r0/a1:  0x00000003  r1/a2:  0x00000007  r2/a3:  0x00000006
[00:01:13.078,399] <err> os: r3/a4:  0x20002218 r12/ip:  0x20007bb0 r14/lr:  0x0001fe37
[00:01:13.078,399] <err> os:  xpsr:  0x41000011
[00:01:13.078,430] <err> os: Faulting instruction address (r15/pc): 0x00029628
[00:01:13.078,460] <err> os: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
[00:01:13.078,460] <err> os: Fault during interrupt handling

[Einar Thorsrud]

Hi,

This assert indicates a timing related issue of some sort, where the SoftDevice was delayed for too long for some reason. A typical reason for that is high priority interrupts that block for too long, or critical sections that block for too long, and similar, which I understand is what you have already suspected. The assert does not tell us anything more precisely about what blocked it, though.