nRF52840 DK- Softdevice events handling

RE: nRF52840 DK- Softdevice events handling

bjorn-spockeli — Wed, 26 Feb 2020 07:22:18 GMT

Yes, its a tad complicated with the debounce timer and function pointer being passed around. However, from a top level the app_button module is quite easy to use and understand :)

RE: nRF52840 DK- Softdevice events handling

ACAMP — Tue, 25 Feb 2020 18:25:44 GMT

what a story.

Thanks

RE: nRF52840 DK- Softdevice events handling

bjorn-spockeli — Tue, 25 Feb 2020 07:55:09 GMT

Yes, the event handler is passed to app_button_init as a the button_handler member of the app_button_cfg_t struct in the buttons array. The buttons array of type app_button_cfg_t is saved to an internal variable, mp_buttons, in app_button.c.

When ever a pin in the buttons array is pressed the app_button module will start an application timer that acts as a debounce timer, i,e, the pin is check when the interrupt is triggered, then you wait for a short period for the voltage level to stabilize on the pin before you check the state of the pin again. In app_button.c the last step is done in detection_delay_timeout_handler() where you see that the mp_buttons array, which is identical to the buttons array passed to app_button_init, is traversed and the evt_handle() is called if there is a state change.

In evt_handle the state is processed and the usr_event() function is called which looks up the configuration for the given pin and then calls the button_handler() function, which is the function pointer to button_event_handler.

/* Find configuration structure for given pin. */
static app_button_cfg_t const * button_get(uint8_t pin)
{
    for (int i = 0; i < m_button_count; i++)
    {
        app_button_cfg_t const * p_btn = &mp_buttons[i];
        if (pin == p_btn->pin_no) {
            return p_btn;
        }
    }

    /* If button is not found then configuration is wrong. */
    ASSERT(false);
    return NULL;
}

static void usr_event(uint8_t pin, uint8_t type)
{
    app_button_cfg_t const * p_btn = button_get(pin);

    if (p_btn && p_btn->button_handler)
    {
        NRF_LOG_DEBUG("Pin %d %s", pin, (type == APP_BUTTON_PUSH) ? "pressed" : "released");
        p_btn->button_handler(pin, type);
    }
}

RE: nRF52840 DK- Softdevice events handling

ACAMP — Mon, 24 Feb 2020 22:25:26 GMT

Another thread question: Button notification

for the same example code:

nRF5SDK160098a08e2\examples\ble_peripheral\ble_app_blinky\pca10056\s140\ses

Button notification:

Could you explain how button_event_handler () get called ?

Looks like when button is pressed, GPIO interrupt is triggered and serviced, but how does the GPIO interrupt service trigger button_event_handler () ? My guess is that is done somehow by function pointer ?

Could you explain?

Thanks a lot !

RE: nRF52840 DK- Softdevice events handling

bjorn-spockeli — Mon, 24 Feb 2020 07:33:14 GMT

Yes, in the ble_app_blinky example its the BLE_LBS_DEF() macro that is used to register the ble_lbs_on_ble_evt() event handler for the Led Button Service.

#define BLE_LBS_DEF(_name)                                                                          \
static ble_lbs_t _name;                                                                             \
NRF_SDH_BLE_OBSERVER(_name ## _obs,                                                                 \
                     BLE_LBS_BLE_OBSERVER_PRIO,                                                     \
                     ble_lbs_on_ble_evt, &_name)

Best regards

Bjørn

RE: nRF52840 DK- Softdevice events handling

ACAMP — Sat, 22 Feb 2020 00:24:13 GMT

I think I figure it out.

There is macro BLE_LBS_DEF(m_lbs); in main () file

Thanks

RE: nRF52840 DK- Softdevice events handling

ACAMP — Fri, 21 Feb 2020 17:31:32 GMT

That makes great sense to me.

I do have a follow up question.

For ble_app_blinky example, " nRF5SDK160098a08e2\examples\ble_peripheral\ble_app_blinky\pca10056\s140\ses "

Now, I understand ble_evt_handler is registered through NRF_SDH_BLE_OBSERVER.

My question is about: How the LED write function get executed from smartphone to Softdevice event and then to application code " on_write () "?

Looks like LED write event handle is registered through sd_ble_gatts_service_add( ) API?

Beside NRF_SDH_BLE_OBSERVER, we can also register an event handle by sd_ble_gatts_service_add( ) API ?

Thanks a lot !

static void on_write(ble_lbs_t * p_lbs, ble_evt_t const * p_ble_evt)

void ble_lbs_on_ble_evt(ble_evt_t const * p_ble_evt, void * p_context)

err_code = sd_ble_gatts_service_add(BLE_GATTS_SRVC_TYPE_PRIMARY, &ble_uuid, &p_lbs->service_handle);

RE: nRF52840 DK- Softdevice events handling

bjorn-spockeli — Fri, 21 Feb 2020 12:57:19 GMT

HI Acamp

The SoftDevice uses the EGU(Event Generator Unit) to generate a software interrupt to notify the application about BLE and SOC events. So both SoC and BLE events from the SoftDevice are signaled through SWI2_EGU2_IRQHandler, here sdh_evts_poll() is called which in turns notifies all observers registered through the NRF_SDH_STACK_OBSERVER() macro, i.e. nrf_sdh_ble_evts_poll() and nrf_sdh_soc_evts_poll(). These functions will in turn notify all the observers registered through the NRF_SDH_BLE_OBSERVER() and NRF_SDH_SOC_OBSERVER() macros.

So when an observer ( i.e. an event handler ) is registered through the NRF_SDH_BLE_OBSERVER or NRF_SDH_SOC_OBSERVER macros, then the function pointer to the event handler is stored in a specific section in flash. The nrf_sdh_soc_evts_poll() and nrf_sdh_ble_evts_poll() functions will iterate through this section and call the handler functions through the function pointers stored in the section. This section will also be ordered depending on which priority that was assigned to the handler.

Lets take a practical example, in the ble_app_hrs example you'll see the following macro at the top of main.c.

BLE_HRS_DEF(m_hrs);

Going to the definition, we see that this macro registers the ble_hrs_on_ble_evt() function as the handler and assign it BLE_HRS_BLE_OBSERVER_PRIO (its set to 2) as the priority. The BLE_HRS_BLE_OBSERVER_PRIO priority is set in the sdk_config.h file

#define BLE_HRS_DEF(_name)                                                                          \
static ble_hrs_t _name;                                                                             \
NRF_SDH_BLE_OBSERVER(_name ## _obs,                                                                 \
                     BLE_HRS_BLE_OBSERVER_PRIO,                                                     \
                     ble_hrs_on_ble_evt, &_name)

If we look at ble_stack_init() in the same example, we see that it registers ble_evt_handler() as the handler function with priority APP_BLE_OBSERVER_PRIO( which is set to 3).

static void ble_stack_init(void)
{
    ret_code_t err_code;

    err_code = nrf_sdh_enable_request();
    APP_ERROR_CHECK(err_code);

    // Configure the BLE stack using the default settings.
    // Fetch the start address of the application RAM.
    uint32_t ram_start = 0;
    err_code = nrf_sdh_ble_default_cfg_set(APP_BLE_CONN_CFG_TAG, &ram_start);
    APP_ERROR_CHECK(err_code);

    // Enable BLE stack.
    err_code = nrf_sdh_ble_enable(&ram_start);
    APP_ERROR_CHECK(err_code);

    // Register a handler for BLE events.
    NRF_SDH_BLE_OBSERVER(m_ble_observer, APP_BLE_OBSERVER_PRIO, ble_evt_handler, NULL);
}

So whenever a BLE event is signaled by the SoftDevice, then the call stack will roughly be like this SWI2_EGU2_IRQHandler -> nrf_sdh_ble_evts_poll() -> ble_hrs_on_ble_evt -> ble_evt_handler. So ble_hrs_on_ble_evt will be called first by nrf_sdh_ble_evts_poll as it has a higher priority than ble_evt_handler.

I hope that clarifies it. If not, then just post additional question in comments.

Best regards

Bjørn