Timeslot API

RE: Timeslot API

Einar Thorsrud — Mon, 21 Jun 2021 08:28:48 GMT

Hi,

The error code, line number and file name is only relevant for SDK errors. When there is a SoftDevice assert you need to look at the PC. If you are using the default app_error_fault_handler() in SDK 15.3 it looks like this:

__WEAK void app_error_fault_handler(uint32_t id, uint32_t pc, uint32_t info)
{
    __disable_irq();
    NRF_LOG_FINAL_FLUSH();

#ifndef DEBUG
    NRF_LOG_ERROR("Fatal error");
#else
    switch (id)
    {
#if defined(SOFTDEVICE_PRESENT) && SOFTDEVICE_PRESENT
        case NRF_FAULT_ID_SD_ASSERT:
            NRF_LOG_ERROR("SOFTDEVICE: ASSERTION FAILED");
            break;
        case NRF_FAULT_ID_APP_MEMACC:
            NRF_LOG_ERROR("SOFTDEVICE: INVALID MEMORY ACCESS");
            break;
#endif
        case NRF_FAULT_ID_SDK_ASSERT:
        {
            assert_info_t * p_info = (assert_info_t *)info;
            NRF_LOG_ERROR("ASSERTION FAILED at %s:%u",
                          p_info->p_file_name,
                          p_info->line_num);
            break;
        }
        case NRF_FAULT_ID_SDK_ERROR:
        {
            error_info_t * p_info = (error_info_t *)info;
            NRF_LOG_ERROR("ERROR %u [%s] at %s:%u\r\nPC at: 0x%08x",
                          p_info->err_code,
                          nrf_strerror_get(p_info->err_code),
                          p_info->p_file_name,
                          p_info->line_num,
                          pc);
             NRF_LOG_ERROR("End of error report");
            break;
        }
        default:
            NRF_LOG_ERROR("UNKNOWN FAULT at 0x%08X", pc);
            break;
    }
#endif

    NRF_BREAKPOINT_COND;
    // On assert, the system can only recover with a reset.

#ifndef DEBUG
    NRF_LOG_WARNING("System reset");
    NVIC_SystemReset();
#else
    app_error_save_and_stop(id, pc, info);
#endif // DEBUG
}

When you get a NRF_FAULT_ID_SD_ASSERT, the relevant here is the value of the pc parameter. I you can tell me what it is, and the exact SoftDevice version you use I can check which assert failed. Without it, I can only make assumptions like in my previous post.

RE: Timeslot API

xixili — Fri, 18 Jun 2021 06:25:33 GMT

SoftDevice assert:

m_error_data.err_code=0,m_error_data.line_num=0,m_error_data.p_file_name=NULL

RE: Timeslot API

Einar Thorsrud — Thu, 17 Jun 2021 14:03:04 GMT

It would be good to know which SoftDevice assert you get, as I explained. Without knowing it there are still a few things you can do:

* Doubel check that you always properly disable interrupts etc for devices that the SoftDevice use before the end of the timeslot (like the Radio and TIMER0).

* Add some margin so that you end the timeslot a bit earlier than you normally should have to. This can be especially relevant if you time the duration of the timeslot sing a timer (which runs of the HF clock), as the SoftDevice relies on RTC0 in this case (which runs of the LF clock). If there is more drift between these clocks for some reason, more margin would help.

RE: Timeslot API

xixili — Thu, 17 Jun 2021 13:53:09 GMT

So how should I solve this problem? timeslot refers to your code

RE: Timeslot API

Einar Thorsrud — Thu, 17 Jun 2021 12:07:30 GMT

That makes sense. Can you cheche which assert you get, meaning which program counter value? You can typically see that from the app_error_fault_handler when you get a NRF_FAULT_ID_SD_ASSERT (it is called with pc as a parameter).

In most cases with SoftDevice asserts when using timeslot it is related to the application either not cleaning up properly or using resources outside of the timeslot for some reason.

RE: Timeslot API

xixili — Thu, 17 Jun 2021 10:33:50 GMT

Call sd_radio_request(&m_timeslot_request) once every 3 seconds; after sending thousands of times, an error may appear SOFTDEVICE: ASSERTION FAILED

ASSERTION FAILED

RE: Timeslot API

Einar Thorsrud — Tue, 08 Jun 2021 13:10:14 GMT

I understand. But there is not enough to go on for me to consider what could cause this. Have you done any debugging? What have you found out? Please elaborate.

RE: Timeslot API

xixili — Tue, 08 Jun 2021 13:03:19 GMT

Radio interruption will appear at the beginning, but it will be lost after a period of time. Sometimes it is a day, sometimes a few days, and it may appear in a few hours soon. Why is there no radio interruption

RE: Timeslot API

Einar Thorsrud — Tue, 08 Jun 2021 12:57:40 GMT

Hi,

I see. So you are waiting for a radio interrupt that does not happen. Is this still within a timeslot? Have you debugged to verify that you have some radio activity that should have caused a radio interrupt? Please elaborate / provide much more details so that I can better understand what could be going on.

RE: Timeslot API

xixili — Tue, 08 Jun 2021 12:53:41 GMT

Set up a timeslot, use ble and radio at the same time, after a long period of use, conflicts will occur, and the protocol stack will be reset abnormally. I found that it was caused by no radio interruption, how should I solve it?

Refer to devzone.nordicsemi.com/.../setting-up-the-timeslot-api

RE: Timeslot API

Einar Thorsrud — Tue, 08 Jun 2021 11:41:32 GMT

Hi,

I do not fully understand the context of this question. Can you please elaborate / explain in more detail what you do and what the issue is?