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

Handling SoftDevice events yourself and the need for nrf_sdh_ related calls

I handle events directly by invoking the following code after the sd_app_evt_wait(); call:

        while(true)
        {
           // uint32_t evt_id;

            // Don't do this if disabled, for example when writing flash at the end
            sd_softdevice_is_enabled(&enabled); // Don't do this if disabled, for example when writing flash at the end
            if (enabled != 1)
            {
                NRF_LOG_DEBUG("Restarting application");
                while(NRF_LOG_PROCESS());
                NVIC_SystemReset();
                return;
            }
            result = sd_ble_evt_get(NULL, &len);    // Get size of event
            if (result == NRF_ERROR_NOT_FOUND)      // If there aren't any, go back to wait
            {
                break;
            }
            evt_buf = (uint8_t *)calloc(1, len);                // Make space for event. evt_buf is 4-byte aligned
            result = sd_ble_evt_get((uint8_t *)evt_buf, &len);  // get the event
            if (result == NRF_SUCCESS)
            {
                ble_evt_t *evt = (ble_evt_t *)evt_buf;
                ble_evt_dispatch(evt);                          // dispatch event to handler. This handles only BTLE related events
            }
            else                                                // Hopefully no error but just in case log it.
            {                                                   // Should I do an NVIC_SystemReset() here?
                NRF_LOG_DEBUG("PENDING BLE Event return error: %u", result);
                free(evt_buf);  // Clean up
                break;          // back to wait
            }
            free(evt_buf);      // clean up and get the next event
        }

I poll the events and dispatch them to my handler as needed.

Now if I do this, do I need to make calls to nrf_sdh_enable_request()

and

nrf_sdh_ble_default_cfg_set(APP_BLE_CONN_CFG_TAG, &ram_start); ?

I will need to make some sd_ble_cfg_set() calls but what I am really wondering about is the so-called 'observers'. My app already makes the sd_ble_evt_get() calls so it doesn't seem that I need to tell any other 'observers' who is using SoftDevice. Am I missing something?

I am mainly concerned about these calls in nrf_sdh_ble_default_cfg_set()

ble_cfg.gap_cfg.role_count_cfg.central_role_count = NRF_SDH_BLE_CENTRAL_LINK_COUNT;
    ble_cfg.gap_cfg.role_count_cfg.central_sec_count  = MIN(NRF_SDH_BLE_CENTRAL_LINK_COUNT,
                                                            BLE_GAP_ROLE_COUNT_CENTRAL_SEC_DEFAULT);

    ret_code = sd_ble_cfg_set(BLE_GAP_CFG_ROLE_COUNT, &ble_cfg, *p_ram_start);

since I need to use both central and peripheral roles -  well at least partly. I have a peripheral that gets its data from unconnectable broadcasts, so I need to implement a scanner to get these broadcasts while the peripheral is connected.

Parents
  • Hi,

    I recall from older cases that you did not use much SDK code. If you rely on only SoftDevice API's, then you do not need the SDH library, and can ignore everything related to it.

    The "observers" are other SDK components that subscribe to SoftDevice events. If you do not use any such SDK libraries, then this is not relevant. If you do, it is. I do not know enough of your application to say which is the case, though.

  • That information is very helpful - THat being said I am not sure where the SDK starts and where it ends with respect to SoftDevice. That part of the SDK that I am not using is related to BTLE and writing to flash. All the other features related to chip support and language support such as the clock, uart, etc. may or may not be part of SoftDevice. They all have prefixes nrf so I am not sure where the line is. I DO know there are SoftDevice calls related to 'Soc'.

    So all I DO know is that I am using sd_ calls for all Bluetooth low energy functionality and writing to flash. So I need to tread cautiously as there may be observers for events that are not BTLE related that must be preserved. That's what I am concerned about.

  • Hi,

    brianreinhold said:
    They all have prefixes nrf so I am not sure where the line is. I DO know there are SoftDevice calls related to 'Soc'.

    That is correct.

    brianreinhold said:
    So I need to tread cautiously as there may be observers for events that are not BTLE related that must be preserved. That's what I am concerned about.

    Which SDK libraries do you use? Do you use any libraries that rely on SoftDevice events? If so, this may be relevant. if not, it is not.

  • To be honest, I am not sure what libraries I use. I started with the hts (health thermometer example) and coded my generic health sensor peripheral from there. I removed libraries and source I knew that I no longer used (like all the btle services and files, the peer manager and storage) but the others I am not so sure about. I use the timer but that again is to simulate the arrival of fake live measurements, I do use the time clock to get time ticks, I do use the button presses to fake stored data and start advertising and disconnect the peripheral, and the UART for NRF_LOG. Otherwise I handle all events by using the sd_get method after the sd_app_evt_wait function (if I remember correctly) wakes up.

    So what I have been doing is removing a library that I think I don't need and seeing if it still works. Lousy approach but it has whittled down the size of the project - perhaps making it less scary for a newbie looking at it (I want to make as simple as possible and as easy as possible to port between the various SoftDevices and nrf5* platforms).

  • I cannot really say if this is OK or not without knowing what you use.

  • I understand. And I do not know what I use as I started with the hts and I don't know everything that it uses. So I may be using components of the library without realizing it. For example, I use NRF_LOG, but I cannot remove the FPRINTF library even though I don't use it directly. BUT it turns out that one of the NRF_LOG methods (the string method) DOES call the fprintf methods under the hood so I have to keep that library. I do not know how many other similar situations there may be. Just looking at the library calls I make directly is not sufficient!

  • Only libraries that use resources that are controlled by the SoftDevice are relevant in this case, and you can see that from table 2 under Hardware peripherals in the SoftDevice specification.

Reply Children
No Data
Related