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]

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

[rgrr2]

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