This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NRF_FAULT_ID_SD_ASSERT with pc0x252f2 and 0x16e5a

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

Parents
  • 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

  • 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

Reply
  • 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

Children
Related