NRF_FAULT_ID_SD_ASSERT with pc0x252f2 and 0x16e5a

[balo0801]

Hi Nordic team,

I am currently developing a concurrent wireless application with BLE and a proprietary protocol using the timeslot API.

My setup:

• nRf52840 DK
• SDK: 15.2.0
• S140: 6.1.1

After running my application some time I always to stuck in some errors:

• NRF_FAULT_ID_SD_ASSERT with pc 0x252f2 and info 0
• NRF_FAULT_ID_SD_ASSERT with pc 0x16e5a and info 0

As debugging is quite hard without any information about the assertions, it would be awesome if you can provide me some more informations about them.

What is the background of those assertions? Is there somewhere a description available?

Best regards,

Mario

[Håkon Alseth]

Hi,

 

Are you using the timeslot API?

The assertion info points to a timeslot that has exceeded its assigned slot.

In the _START callback, you normally set a timer expiration, like "NRF_TIMER0->CC[0] = m_slot_length - 1000;"


Could you try to adjust this?

 

Kind regards,

Håkon

[balo0801]

Hi Håkon,

yes I use the Timeslot API.

 

In my _START callback I used initially:

NRF_TIMER0->CC[0] = m_slot_length - 100;

But adapted it now to your proposal, without observing a different behavior.

 

Using the following Timeslot request:

mg_TimeslotRequest.request_type = NRF_RADIO_REQ_TYPE_EARLIEST;
mg_TimeslotRequest.params.earliest.hfclk = NRF_RADIO_HFCLK_CFG_XTAL_GUARANTEED;
mg_TimeslotRequest.params.earliest.priority = NRF_RADIO_PRIORITY_HIGH;
mg_TimeslotRequest.params.earliest.timeout_us = 100000;
mg_TimeslotRequest.params.earliest.length_us = 1000000;

printf("--> start request\n");
SoftDeviceStatus = sd_radio_request( &mg_TimeslotRequest );
printf("--> request done\n");

 

In my log then I see the following:

2020-02-04 11:29:25.178: 6.227 --> start request
2020-02-04 11:29:25.179: 6.228 --> request done
2020-02-04 11:29:25.681: 6.631 --> start request
2020-02-04 11:29:25.682: 6.730
2020-02-04 11:29:25.687: 6.730 ==================================================
2020-02-04 11:29:25.689: 6.730 app_error_fault_handler:
2020-02-04 11:29:25.691: 6.730 SOFTDEVICE: ASSERTION FAILED, PCxxx: 0x252f2, info: 0
2020-02-04 11:29:25.693: 6.731 ==================================================

So what I observe is that the assertions failes after roughly executing "sd_radio_request()" for about roughly 100 ms.

Is this Softdevice function blocking? Do you have an idea why it takes 100 ms?

Best regards,

Mario

[Håkon Alseth]

Are you running the proprietary protocol directly from the timeslot? if so, you will inherit the interrupt priority 0, which will cause the timer0 interrupt to occur after you have returned from your called function. Could you try running your protocol in a software interrupt or schedule it to main priority (setting a boolean flag or similar)?

 

Kind regards,

Håkon