SoftDevice Controller ASSERT: 53, 607 in custom HCI_RPMsg nRF5340 net cpu

[Austin Hellenbrand]

Hello, 

I am working on integrating wireless-timer-synchronization into the HCI_RPMsg sample provided with nRF Connect SDK. My goal is to synchronize ADC sampling between BLE Peripheral devices all connected to a single central device. The central device transmits sync packets and the peripherals listen for them. I followed the updating to the mpsl timeslot interface post to update the timer synchronization code to use mpsl timeslots and it is working for the most part.

nRF Connect SDK: v1.9.0

Board: nRF5340DK v2.0.0

The code runs as expected when running on the peripheral device (Rx mode), but when I run the exact same image on the central (Tx mode) I get the following exception:

[00:00:45.308,441] <err> sdc_hci_driver: SoftDevice Controller ASSERT: 53, 607
[00:00:45.308,471] <err> os: ***** HARD FAULT *****
[00:00:45.308,471] <err> os:   Fault escalation (see below)
[00:00:45.308,471] <err> os: ARCH_EXCEPT with reason 3

[00:00:45.308,502] <err> os: r0/a1:  0x00000003  r1/a2:  0x00000007  r2/a3:  0x00000006
[00:00:45.308,532] <err> os: r3/a4:  0x21001868 r12/ip:  0xf7bfded5 r14/lr:  0x0102441f
[00:00:45.308,532] <err> os:  xpsr:  0x4100001c
[00:00:45.308,532] <err> os: r4/v1:  0x00000441  r5/v2:  0x0000025f  r6/v3:  0x210077a0
[00:00:45.308,532] <err> os: r7/v4:  0x00000000  r8/v5:  0x00000000  r9/v6:  0x00000000
[00:00:45.308,563] <err> os: r10/v7: 0x00000000  r11/v8: 0x00000000    psp:  0x21006fc0
[00:00:45.308,563] <err> os: EXC_RETURN: 0xffffffb0
[00:00:45.308,563] <err> os: Faulting instruction address (r15/pc): 0x01028ea2
[00:00:45.308,563] <err> os: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
[00:00:45.308,563] <err> os: Fault during interrupt handling

[00:00:45.308,593] <err> os: Current thread: 0x21001c70 (idle 00)
[00:00:45.456,726] <err> os: Halting system

The only difference is that the peripheral is using the radio in Rx mode, while the transmitter is using it in Tx mode. The exception occurs after the first timeslot has ended. 

I have verified that the radio is disabled before the timeslot ends. The "timeslot is ending" callbacks for Rx and Tx modes are practically identical, the only thing different is the DPPI channel that gets cleared. 

Can someone shed some light on what this assert means? 

[Amanda Hsieh]

Hi, 

I am looking into this case and will reply next week.

Regards,
Amanda 

[Amanda Hsieh]

Hi, 

Sorry for the delay. 

The assert happens in the central scheduling, the central context is NULL while REM receives a signal.

Can you elaborate on more details of the application? How many peripherals, and when exactly the assert happens? Is the central able to send any sync packet before the assert happens?

-Amanda

[Austin Hellenbrand]

Hi, 

The application is a modified version of the HCI_RPMsg provided in the SDK. The only modification is the inclusion of the ported time sync and timeslot code. The time sync code has been ported to use mpsl timeslots, since the original time sync demo used SoftDevice. I'm handling the timeslot using timeslot.c and timeslot.h from the updating to the mpsl timeslot post. 

I am currently only connecting to one peripheral, but eventually I will need to connect with up to 8 peripherals. 

Once the central device finishes establishing a connection with the peripheral, it starts requesting timeslots for the time sync. During the very first timeslot, sync packets are transmitted just fine. The assert happens when that timeslot finishes and control is handed back to the BLE controller. 

Thanks for looking into this,

Austin Hellenbrand

[Amanda Hsieh]

Hi, 

From the team:

The assertion indicates that the interrupt priorities of the RTC0 and RADIO are not equal which is a requirement of our stack, so it's caused by a bug in your application. 

-Amanda

[Austin Hellenbrand]

Hello, 

That was indeed the issue. The radio interrupt priority was getting set to 2 even though I was passing 0 to  IRQ_DIRECT_CONNECT. Adding the IRQ_ZERO_LATENCY flag to IRQ_DIRECT_CONNECT fixes the issue.