Application fault in SoftDevice

RE: Application fault in SoftDevice

Jake Yun — Thu, 27 Aug 2020 23:37:12 GMT

Thank you very much for the answer.

Best regars,
Jake

RE: Application fault in SoftDevice

Marjeris Romero — Thu, 27 Aug 2020 14:04:53 GMT

Hi,

Assert 0x01505C can happen independently of timeslot use, but you can also get it for overstaying in a timeslot.

Assert 0x025b94 happens in the timeslot api implementation.

RE: Application fault in SoftDevice

Jake Yun — Wed, 26 Aug 2020 00:10:18 GMT

Dear Marjeris Romero, please answer to my final question.

Thank you.

Best regards,
Jake

RE: Application fault in SoftDevice

Jake Yun — Thu, 20 Aug 2020 00:31:03 GMT

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.

[quote userid="73427" url="~/f/nordic-q-a/64238/application-fault-in-softdevice/264437"]This assert can happen if the application disables interrupt globaly at unfortunate times, or has missconfigured one of its interrupts to have highest priority.[/quote]

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

RE: Application fault in SoftDevice

Marjeris Romero — Thu, 13 Aug 2020 11:18:15 GMT

Hi Jake,

[quote user="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().[/quote]

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

RE: Application fault in SoftDevice

Jake Yun — Wed, 12 Aug 2020 09:41:59 GMT

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

RE: Application fault in SoftDevice

Marjeris Romero — Wed, 12 Aug 2020 09:09:52 GMT

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

RE: Application fault in SoftDevice

Jake Yun — Wed, 12 Aug 2020 07:04:25 GMT

Marjeris Romero Dear Marjeris, do you have any question to my comment? or are you working on it? or was it forwarded to developers?
Please update the progress.

Thank you.

Best regards,
Jake

RE: Application fault in SoftDevice

Jake Yun — Mon, 10 Aug 2020 00:41:32 GMT

Dear Marjeris,

Please note that the code is written to show the error case which raises assertion with PC 0x25B94 while PC 0x1505C is expected.

It might be answered by developer side who has the source code of softdevice.

Thank you.

Best regards,

Jake

RE: Application fault in SoftDevice

Marjeris Romero — Fri, 07 Aug 2020 13:00:15 GMT

Hi BS,

Håkon is on vacation so I am taking over this case for now.

Both asserts have to do with radio event manager in Timeslot API. From your code it doesn't seem like you ending the timeslot, since only NRF_RADIO_SIGNAL_CALLBACK_ACTION_NONE is returned, but NRF_RADIO_SIGNAL_CALLBACK_ACTION_END is never returned.

Perhaps the asserts can be resolved if stopping the timeslot a bit earlier?

Best regards,

Marjeris

RE: Application fault in SoftDevice

BS Gwak — Fri, 07 Aug 2020 00:01:17 GMT

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.

RE: Application fault in SoftDevice

Jake Yun — Tue, 04 Aug 2020 00:29:32 GMT

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.

RE: Application fault in SoftDevice

BS Gwak — Thu, 30 Jul 2020 05:37:42 GMT

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;

}

RE: Application fault in SoftDevice

BS Gwak — Wed, 29 Jul 2020 09:17:45 GMT

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.

RE: Application fault in SoftDevice

Hakon — Wed, 29 Jul 2020 08:14:31 GMT

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.

RE: Application fault in SoftDevice

Jake Yun — Wed, 29 Jul 2020 02:55:34 GMT

Ok. I will be waiting.

Thank you for the update.

RE: Application fault in SoftDevice

Hakon — Tue, 28 Jul 2020 15:14:19 GMT

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.

RE: Application fault in SoftDevice

Jake Yun — Tue, 28 Jul 2020 00:36:33 GMT

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.

RE: Application fault in SoftDevice

BS Gwak — Mon, 27 Jul 2020 09:46:04 GMT

Is there any update?

RE: Application fault in SoftDevice

BS Gwak — Wed, 22 Jul 2020 01:43:17 GMT

Yes, timeslot is using and interrupts are disabled sometimes. However, because 'CRITICAL_REGION' is used, I believe that it doesn't affect on SD scheduling. Am I wrong?

If I don't return 'NRF_RADIO_SIGNAL_CALLBACK_ACTION_END' properly, app fault in 0x25B94 is occurred.

What is the difference between two faults?

RE: Application fault in SoftDevice

Hakon — Mon, 20 Jul 2020 12:35:06 GMT

Hello,

[quote user=""]Would you let me know when this assertion is raised on SD?[/quote]

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