Timeslots and SOFTDEVICE: ASSERTION FAILED, PCxxx: 0x2552e

[rgrr2]

Hello

in our concurrent radio application using timeslot API there are failed assertions from time to time (10min - 10h).

Message is as above.

Stacktrace and system state shows clearly that the failed assertion happens during sd_radio_request().  Parameters are:

Details:{request_type = 1 '\001', params = {earliest = {hfclk = 1 '\001', priority = 0 '\0', length_us = 69977, timeout_us = 55000}, normal = {hfclk = 1 '\001', priority = 0 '\0', distance_us = 69977, length_us = 55000}}}

So my question is: what does this address means?  Is there any list of failed assertion addresses with their meanings?

Ah, yes: it happens with SD 6.1.0.  With 6.1.1 one gets the same(?) assertion with a slightly different address.

And no: assigned timeslots were not exceeded.

Thanks & regards

Hardy

[rgrr2]

I doubt it.  At least my softdevice code shows

00025506:   beq.n   0x2551c
00025508:   movs    r0, #15
0002550a:   pop     {r4, r5, r6, pc}
0002550c:   movs    r0, #16
0002550e:   pop     {r4, r5, r6, pc}
00025510:   movs    r0, #7
00025512:   pop     {r4, r5, r6, pc}
00025514:   mov     r0, r5
00025516:   bl      0x251ca
0002551a:   b.n     0x25524
0002551c:   movs    r1, #0
0002551e:   mov     r0, r5
00025520:   bl      0x25208
00025524:   ldr     r1, [pc, #16]   ; (0x25538)
00025526:   ldrb    r0, [r4, #3]
00025528:   bl      0x150a0
0002552c:   cbnz    r0, 0x25530
0002552e:   svc     255     ; 0xff
00025530:   movs    r0, #0
00025532:   pop     {r4, r5, r6, pc}
00025534:   lsls    r4, r1, #7
00025536:   movs    r0, #0
00025538:   asrs    r4, r5, #13
0002553a:   movs    r0, #0
0002553c:   strh    r5, [r7, #48]   ; 0x30
0002553e:   movs    r1, r0
00025540:   subs    r7, r7, #7

[Susheel Nuguru]

Sorry , I was looking at wrong variant map file.

the assert happens in sd_radio_request while requesting a radio slot inside the lower layer. It could fail when making a request on a session that has pending signals is rejected and this will cause an assert.

[Susheel Nuguru]

We have noticed that some other customer had the same problem when they did something illegal with RADIO priority when used other protocols.

If you are using ESB or any other protocol, please make sure that by the time the timeslot is finished, you should switch the RADIO and Timer priority to what they were before.

[rgrr2]

Susheel, you are (perhaps) my hero!

I don't want to be too euphoric, but we have a "NVIC_SetPriority(RADIO_IRQn, 1);" in our code (actually don't know why).

I have removed this line of code and the application has been running now for ~2h on two targets.

That happened before as well, so I will make a longer term test over the weekend and will report the result.

Hardy

[Susheel Nuguru]

Great to know that it could be the issue. I'll wait for your results