Timeslot API

[xixili]

I use SDK 15.3, nrf52840.

https://devzone.nordicsemi.com/nordic/short-range-guides/b/software-development-kit/posts/setting-up-the-timeslot-api

Normal use most of the time, after transmitting for a period of time, NRF_RADIO_CALLBACK_SIGNAL_TYPE_RADIO cannot be received.

NRF_RADIO_CALLBACK_SIGNAL_TYPE_START, NRF_RADIO_CALLBACK_SIGNAL_TYPE_TIMER0 can be received，What is the problem？

[Einar Thorsrud]

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?

[xixili]

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

[xixili]

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

[Einar Thorsrud]

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.

[xixili]

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

[Einar Thorsrud]

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.

[xixili]

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

[Einar Thorsrud]

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.

[xixili]

SoftDevice assert:

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

[Einar Thorsrud]

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.