This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

ESB Timeslot - Softdevice event handler

Hi

We are developing the use of ESB together with BLE, using the Timeslot API.

We have been using the known tutorial for the ESB timeslot implementation:

https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/running-micro-esb-concurrently-with-ble

The problem is basically that it seems that the Tx part of the esb_timeslot is only functioning right, when there is ongoing BLE stuff. (Advertising, scanning, connection etc).

If scanning times out or advertising stops, the timeslots begin/end interrupts stops being triggered frequently, which makes sense as we can now get almost all time for ESB.

One thing I discovered is that the following code is not active in the example linked to ealier:

/**@brief Timeslot signal handler.
 */
void nrf_evt_signal_handler(uint32_t evt_id)
{
    uint32_t err_code;

    switch (evt_id)
    {
        case NRF_EVT_RADIO_SIGNAL_CALLBACK_INVALID_RETURN:
            // No implementation needed
            break;

        case NRF_EVT_RADIO_SESSION_IDLE:
            err_code = sd_radio_session_close(); //TODO do we hit this???
            APP_ERROR_CHECK(err_code);
            break;

        case NRF_EVT_RADIO_SESSION_CLOSED:
            // No implementation needed, session ended
            break;

        case NRF_EVT_RADIO_BLOCKED:
            // Fall through

        case NRF_EVT_RADIO_CANCELED:
            err_code = request_next_event_earliest();
            APP_ERROR_CHECK(err_code);
            break;

        default:
            break;
    }
}

I read that earlier this was supposed to be "used" with the following method:

static void sys_evt_dispatch(uint32_t sys_evt)
{
    pstorage_sys_event_handler(sys_evt);
    ble_advertising_on_sys_evt(sys_evt);
    nrf_evt_signal_handler(sys_evt);
}

Also in the comment section of this question they have the same problem:

https://devzone.nordicsemi.com/nordic/short-range-guides/b/software-development-kit/posts/setting-up-the-timeslot-api?CommentId=bb94288c-6a19-481f-85a1-9d80d3224195NRF_SDH_SOC_OBSERVER

I have tried to implement it with the new method of NRF_SDH_SOC_OBSERVER. But I don't seem to get the "nrf_evt_signal_handler" called ever.

Is that a problem regarding the timeslot implementation, when the nrf_evt_signal_handler is not triggered?

I can see that the code from https://github.com/NordicSemiconductor/nrf51-ble-micro-esb-uart doens't care about the nrf_evt_signal_handler, as this is not triggered either in that project.

Hope you can help with some answers or suggestions Slight smile

- Mikkel

Parents
  • Hello Mikkel,

    I suspect what you are seeing is that the nRF goes into system OFF mode when the advertisement times out.

    Can you check if that is the case?

    Most of our ble_peripheral examples have this function:

    static void on_adv_evt(ble_adv_evt_t ble_adv_evt)
    {
        uint32_t err_code;
    
        switch (ble_adv_evt)
        {
            case BLE_ADV_EVT_FAST:
                err_code = bsp_indication_set(BSP_INDICATE_ADVERTISING);
                APP_ERROR_CHECK(err_code);
                break;
            case BLE_ADV_EVT_IDLE:
                sleep_mode_enter();
                break;
            default:
                break;
        }
    }

    Where in the BLE_ADV_EVT_IDLE, which is the event that triggers when the advertisement times out, it will call sleep_mode_enter(); which will basically turn off the nRF, and it will wake up on either a power on reset, or a buttonpress which is configured in sleep_mode_enter() -> bsp_btn_ble_sleep_mode_prepare();

    So I suspect that what you are actually seeing is that the chip is simply put in system off mode, which is almost the same as turning it off. 

    Can you check whether you call sleep_mode_enter() in the BLE_ADV_EVT_IDLE event?

    Best regards,

    Edvin

Reply
  • Hello Mikkel,

    I suspect what you are seeing is that the nRF goes into system OFF mode when the advertisement times out.

    Can you check if that is the case?

    Most of our ble_peripheral examples have this function:

    static void on_adv_evt(ble_adv_evt_t ble_adv_evt)
    {
        uint32_t err_code;
    
        switch (ble_adv_evt)
        {
            case BLE_ADV_EVT_FAST:
                err_code = bsp_indication_set(BSP_INDICATE_ADVERTISING);
                APP_ERROR_CHECK(err_code);
                break;
            case BLE_ADV_EVT_IDLE:
                sleep_mode_enter();
                break;
            default:
                break;
        }
    }

    Where in the BLE_ADV_EVT_IDLE, which is the event that triggers when the advertisement times out, it will call sleep_mode_enter(); which will basically turn off the nRF, and it will wake up on either a power on reset, or a buttonpress which is configured in sleep_mode_enter() -> bsp_btn_ble_sleep_mode_prepare();

    So I suspect that what you are actually seeing is that the chip is simply put in system off mode, which is almost the same as turning it off. 

    Can you check whether you call sleep_mode_enter() in the BLE_ADV_EVT_IDLE event?

    Best regards,

    Edvin

Children
No Data
Related