• State Verified Answer
  • Replies 21 replies
  • Subscribers 74 subscribers
  • Views 4071 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 253342
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Application fault in SoftDevice

BS Gwak

Hi,

My device is using nRF52840 with s140 of SDK v16. BLE feature is used with SD .

Sometimes application hard faults in SD are observed in devices deployed. It is quite random. 

Its PC is 0x1505C and fault id is 1.

Would you let me know when this assertion is raised on SD?

Parents
  • 0

    Hello,

     

    Would you let me know when this assertion is raised on SD?

     This is because of overstayed REM event. Are you using timeslot? Are you locking interrupts, etc?

  • 0 in reply to Hakon

    Hello Hakon,

    I'm working with BS, the first questioner and I will narrow the question.

    1. According to your answer, assertion with PC 0x1505C means "overstayed REM event".

    2. As far as I know assertion with PC 0x25B94 means similar overstaying in REM event.

    3. I can reproduce assertion with PC 0x25B94 by not returning 'NRF_RADIO_SIGNAL_CALLBACK_ACTION_END' and that is clear to me.

    4. QUESTION, what is the difference between the assertions with PC 0x1505C  and PC 0x25B94 ?
        ( As you may know, Assertion with PC 0x1505C  does not happen by just not returning 'XXXX_ACTION_END')

    As BS mentioned, we are suffering from the assertion with PC 0x1505C and I need to know exactly when it happens, to fix it.

    Please leave the answer as soon as possible. The product is in service.

    Thank you.

  • 0 in reply to jake.yoon

    Hi Jake,

    Both assertions indicate that the application has overstayed its allocated timeslot, that's why I suggested that you should try to add more margin.

    Something in the application must be sporadically blocking so the timeslot cannot finish on time.

    Check out this blogpost for more information about timeslot handling: https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/running-micro-esb-concurrently-with-ble

    Best regards,

    Marjeris

  • 0 in reply to Marjeris Romero

    Of course, I know that both assertions are related to a kind of OVERSTAY.

    And Hakon said following.

    0x25B94 means overstaying in the p_radio_signal_callback handler itself while
    0x1505C means overstaying in timeslot, which means NRF_RADIO_SIGNAL_CALLBACK_ACTION_END is returned late.

    BUT I got 0x25B94 in my test with that sample code.
    As you can see, it returns from the p_radio_signal_callback handler as soon as possible.
    It's contrary to Hakon's explanation and that's my question.

    Thank you.

    Best regards,

    Jake

  • +1 in reply to jake.yoon

    Hi Jake,

    Hakon said:
    What most likely happens when you get assert 0x25B94 is that you spend too much time in the p_radio_signal_callback handler that is passed to sd_radio_session_open().

    This was Håkon's suggestion for what could be happening when you get assert 0x25B94. I agree with Håkon that it's very likely that you in some way are overstaying your allocated timeslot. You say that you return from the p_radio_signal_callback handler as soon as possible but I cannot see that from the code snippet you posted earlier. Can you post the code where you return NRF_RADIO_SIGNAL_CALLBACK_ACTION_END?

    You need to end the current timeslot by returning either:

    NRF_RADIO_SIGNAL_CALLBACK_ACTION_END, /**< End the current radio timeslot. */
NRF_RADIO_SIGNAL_CALLBACK_ACTION_REQUEST_AND_END /**< Request a new radio timeslot and end the current timeslot. */

    For the differences between the two asserts I asked one of our Softdevice developers and this was the explanation he gave:

    0x01505c is an assert in the REM low architectural level, it can happen if a role (bluetooth advertiser, bluetooth connection ++, or timeslot api) spends more time than they requested.
    This assert can happen if the application disables interrupt globaly at unfortunate times, or has missconfigured one of its interrupts to have highest priority.
    0x025b94 is in the timeslot api implementation, so higher up in the architecture than 0x01505c, it tries to "catch" when the application has spent to much time in its timeslot. Keep in mind you might get 0x01505c instead of 0x025b94 if you spend to much time in a timeslot.

    So as you can see both asserts are kind of intertwine, and indicate that the application has overstayed its allocated timeslot. Have you tried to debug your timeslot implementation in some way?
    Best regards,
    Marjeris
  • 0 in reply to Marjeris Romero

    Ok, now I found the root cause of the misunderstanding.

    Please have a look at following diagram.
     

    I was distinguishing T1 and T2.
    And I thought that long T1 caused 0x25B94 while long T2 caused 0x01505c.

    But from the last explanation of Softdevice developer, I found that T1 and T2 are not clearly differentiated.

    And here is my last question for one statement in the explanation.

    Marjeris Romero said:
    This assert can happen if the application disables interrupt globaly at unfortunate times, or has missconfigured one of its interrupts to have highest priority.

    This comment makes me feel that there is a possibility of assertion even when the spent time is short if the timing is unfortunate. Is it?

    I'm expecting an answer from you of "only LONG time spending (overstaying) raises the assertion", "the assertion will never happen if T1 and T2 are short".

    Please confirm it to your softdevice developer.
    Thank you.

    Best regards,
    Jake

  • 0 in reply to jake.yoon

    Dear , please answer to my final question.

    Thank you.

    Best regards,
    Jake

Reply Children
No Data
Related
Terms of service