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

[Susheel Nuguru]

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.

[rgrr2]

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.

[Susheel Nuguru]

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.

[rgrr2]

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()

[Susheel Nuguru]

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