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?

[Hakon]

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?

[jake.yoon]

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.

[Hakon]

Hello, I will need to investigate this a bit before I can give you any meaningful answer. Most likely I will have an answer by tomorrow.

[jake.yoon]

Ok. I will be waiting.

Thank you for the update.

[Hakon]

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

When you get 0x1505C it is likely because you don't finish the time slot on time. Another explaination could be that you are locking interrupts for too long, preventing the TIMER- interrupts in the scheduler from being run. Just make sure that you are not spending too long in the critical region as you pointed out.

[BS Gwak]

Thank you for your reply. 

In my test, assertion 0x25B94 is occurred, even when p_radio_signal_callback is returned ASAP. I'll test it again and get back to you.

[BS Gwak]

I tested it again.
But I could get the assertion with PC 0x25B94 with following code while expecting the assertion with PC 0x1505C.

The result is contrary to your explanation of "assert 0x25B94 is that you spend too much time in the p_radio_signal_callback handler" <== the signal handler returns shortly in my case.

Please check 'p_radio_signal_callback' handler that I tested.

static nrf_radio_signal_callback_return_param_t*

_radio_signal_callback(uint8_t sig)

{

    g_signal_callback_return_param.callback_action = NRF_RADIO_SIGNAL_CALLBACK_ACTION_NONE;

 

    switch (sig)

    {

        case NRF_RADIO_CALLBACK_SIGNAL_TYPE_START:                    

            /* trigger task early, the rest of the setup can be done in RXRU */

            NVIC_EnableIRQ(RADIO_IRQn);

            NRF_RADIO->PACKETPTR = (uint32_t)&ble_adv_data[0];            

             NRF_RADIO->SHORTS = RADIO_SHORTS_READY_START_Msk | RADIO_SHORTS_END_DISABLE_Msk;

             NRF_RADIO->INTENSET = RADIO_INTENSET_DISABLED_Msk;

             NRF_RADIO->TASKS_TXEN = 1;

            break;

 

        case NRF_RADIO_CALLBACK_SIGNAL_TYPE_RADIO:          

            break; //for generating the SD assertion of the 0x25b94

 

        default:

            break;

    }

     return &g_signal_callback_return_param;

}

[jake.yoon]

Hakon Dear Hakon, would you please clarify following contradictions?

Contradiction 1

---

Hakon
"assert 0x25B94 is that you spend too much time in the p_radio_signal_callback handler that is passed to sd_radio_session_open()"

---

BS Gwak
assertion 0x25B94 is occurred, even when p_radio_signal_callback is returned ASAP.

---

Contradiction 2

---

Hakon
0x1505C it is likely because you don't finish the time slot on time. Another explanation could be that you are locking interrupts for too long

---

BS Gwak
0x1505C happens sporadically even though the time slot finishes on time and no interrupt locking.

---

Thank you.

[BS Gwak]

Amanda Hsieh Dear Amanda, I saw that you were assigned to this issue. Would you let me know if there is any progress?

Thank you.