Timeslots and SOFTDEVICE: ASSERTION FAILED, PCxxx: 0x2552e

RE: Timeslots and SOFTDEVICE: ASSERTION FAILED, PCxxx: 0x2552e

rgrr2 — Tue, 03 Mar 2020 11:06:31 GMT

Ok Susheel, you are my hero definitely!

One suggestion: it would be great to have an additional chapter in the timeslot API documentation how the slot has be be returned / cleaned up.

But... thanks again.

Hardy

RE: Timeslots and SOFTDEVICE: ASSERTION FAILED, PCxxx: 0x2552e

Susheel Nuguru — Fri, 28 Feb 2020 17:56:39 GMT

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

RE: Timeslots and SOFTDEVICE: ASSERTION FAILED, PCxxx: 0x2552e

rgrr2 — Fri, 28 Feb 2020 12:04:19 GMT

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

RE: Timeslots and SOFTDEVICE: ASSERTION FAILED, PCxxx: 0x2552e

Susheel Nuguru — Fri, 28 Feb 2020 08:33:18 GMT

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.

RE: Timeslots and SOFTDEVICE: ASSERTION FAILED, PCxxx: 0x2552e

Susheel Nuguru — Fri, 28 Feb 2020 08:28:50 GMT

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.

RE: Timeslots and SOFTDEVICE: ASSERTION FAILED, PCxxx: 0x2552e

rgrr2 — Thu, 27 Feb 2020 14:54:41 GMT

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

RE: Timeslots and SOFTDEVICE: ASSERTION FAILED, PCxxx: 0x2552e

Susheel Nuguru — Thu, 27 Feb 2020 14:12:36 GMT

sorry, I missed to see the address.

i checked S140 v6.1.0 at 0x2552E and it does not look like there is code there. It looks like that is reserved space for data. If you see that this is your assert address in the fault handler, then it could be because of the stack corruption which does not show correct faulting address

RE: Timeslots and SOFTDEVICE: ASSERTION FAILED, PCxxx: 0x2552e

rgrr2 — Thu, 27 Feb 2020 13:38:09 GMT

The assertion happens inside the softdevice (0x2552e, see subject). That's why I'm asking you what the actual cause of this (failed) assertion could be.

From internal states and the call stack, I can assure you that the assertion happens during sd_radio_request().

Call stack, if this is of any help (S140 6.1.0):

0xb0af2
0x2003a5d0
0x53f39: __assert_func at errorhandler.c:175:0
0xa4f4f
0x20009772
0x20008f2c
0x20000acc
0x0
0x0
0x0
0x20000acc
0x0
0x2552e
0x1
0x200001cc
0x20005258
0x254e7
0x24add
0x0
0x1ee9c4
0x1eec9f
0x1e0300fd
0x47a69
0x1524d
0x25530
0x6100000b
0x2003a620
0x1000001
0x20005258
0x24211
0x2000b3f8
0x2003ec08
0x2003de0c
0x2003a668
0x2003addc
0xfffffff1
0x20005258
0x20005210
0x1f1bff
0x2
0x47a69
0x46e89: _SlotRequest at TimeslotControl.c:603:26 -> line 603 does sd_radio_request()
0x9d506
0x1000024
0x0
0x1f1bfe
0x20005264
0x2000ba07
0x1f
0x4268
0x0
0x0
0x2000b3f8
0x2003de0c
0x2003a7d8
0x475e3: TimeSlotControl_Request at TimeslotControl.c:721:8 -> line 721 does _SlotRequest()

RE: Timeslots and SOFTDEVICE: ASSERTION FAILED, PCxxx: 0x2552e

Susheel Nuguru — Thu, 27 Feb 2020 13:20:15 GMT

can you please provide us with the proper call stack to understand context properly.

I do not see any instruction address for the fault in your question. If this is an assert, which address caused this?

Combined with call stack info and assert instruction address, we should be able understand the nature of the fault.

RE: Timeslots and SOFTDEVICE: ASSERTION FAILED, PCxxx: 0x2552e

rgrr2 — Thu, 27 Feb 2020 13:11:11 GMT

Sorry, I did not write, that the sd_radio_request() happens during the callback.

The above readout is done post-mortem with the debugger.

sd_radio_request()s are done in NRF_EQU0 context which has an assigned prio of 7.

RE: Timeslots and SOFTDEVICE: ASSERTION FAILED, PCxxx: 0x2552e

Susheel Nuguru — Thu, 27 Feb 2020 12:43:13 GMT

As far as I know your timeslot code runs at highest priority (0) and you are not allowed to call any SVC functions from inside. sd_radio_request would translate to an SVC call which has lower priority than the context you call it in and on ARM Cortex M4 that would cause a hardfault. If you want to reschedule another timeslot that is not the way to do it.