Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

Question in "on_connect" in a BLE app

Hi!

I don't have a problem, I just have a doubt about the "on_connect" function. I opened the UART example from:

  nRF5_SDK_17.1.0_ddde560\examples\ble_peripheral\ble_app_uart\pca10040\s132\ses

In this project, it's used the "on_connect" function from the "ble_conn_params.c", which is a common code found here:

    nRF5_SDK_17.1.0_ddde560\components\ble\common

Here is the code:

static void on_connect(ble_evt_t const * p_ble_evt)
{
    uint8_t  role        = p_ble_evt->evt.gap_evt.params.connected.role;
    uint16_t conn_handle = p_ble_evt->evt.gap_evt.conn_handle;

    if (role != BLE_GAP_ROLE_PERIPH)
    {
        return;
    }

    ble_conn_params_instance_t * p_instance  = instance_get(BLE_CONN_HANDLE_INVALID);

    if (p_instance == NULL)
    {
        send_error_evt(NRF_ERROR_NO_MEM);
        return;
    }

    instance_claim(p_instance, conn_handle);
    p_instance->params_ok = is_conn_params_ok(&p_instance->preferred_conn_params,
                                              &p_ble_evt->evt.gap_evt.params.connected.conn_params,
                                              NRF_BLE_CONN_PARAMS_MAX_SLAVE_LATENCY_DEVIATION,
                                              NRF_BLE_CONN_PARAMS_MAX_SUPERVISION_TIMEOUT_DEVIATION);

    // Check if we shall handle negotiation on connect
    if (m_conn_params_config.start_on_notify_cccd_handle == BLE_GATT_HANDLE_INVALID)
    {
        conn_params_negotiation(conn_handle, p_instance);
    }
}

The problem I see is simplified here:

    uint16_t conn_handle = p_ble_evt->evt.gap_evt.conn_handle;

    conn_params_negotiation(conn_handle, p_instance);

And finally, inside the "conn_params_negotiation":

    err_code = app_timer_start(p_instance->timer_id, timeout_ticks, (void *)(uint32_t)conn_handle);

The first thing I don't understand is why "conn_handle" is treated as an address, since I would expect something like "(void *)(uint32_t)(&conn_handle))". But even if the address was passed as a pointer for the p_context of the timer, the variable will disappear from the stack once the function is exited.

What it would be logical to me is that the address of the "p_ble_evt->evt.gap_evt.conn_handle" is passed to the app_timer_start as the p_context so that it can be recovered back in the timer callback handler. 

The code works, but I don't know if it works because the variable is not overwritten in the stack due to a good luck, or if the code is correctly coded and I am missing something...

Thanks!

Parents
  • Hello,

    Thank you for contacting DevZone at NordicSemi.

    I will have a look at this code and will come back.

    However, we recommend our customers to use the latest version of Nordic Connect SDK (NCS)

    /BR, Naeem

  • Hi Naeem!

    I thought I was using the last one. If I go to the nRF5-SDK download site, I see the last one is the 17.1.0, which is the one I'm using (you can check this in the path I showed in my initial post: nRF5_SDK_17.1.0_ddde560). Is that wrong?

    Thanks! 

  • Hi Bernat,

    As you have pointed to the code:

    The function conn_params_negotiation() takes a number conn_handle as an input argument. It then passes this number (conn_handle) as a pointer (not the address of the number, but rather the number itself) to the app_timer_start() function.
    The function app_timer_start() has the following prototype:

    ret_code_t app_timer_start(app_timer_id_t timer_id, uint32_t timeout_ticks, void * p_context);

    the parameter p_context will be passed to the time-out-handler
    When we look at the timeout handler function ( update_timeout_handler() ), we see that the pointer p_context is not dereferenced, but just type casted and stored as a value.
    uint32_t conn_handle = (uint32_t)p_context;

    This could have been an implementation choice as the conn_handle is just a number and does not contain big data stored as a structure.

    Regarding the SDK, please go through Nordic's NCS and NRF5 statement.

    Please also note that Nordic is still supporting the nRF5 SDK in maintenance mode. This means that bug fixes and security updates will be available as needed. However, support for new features beyond Bluetooth LE 5 will not be added to the nRF5 SDK. For instance, Bluetooth Direction Finding, Bluetooth LE Audio, and so forth are not supported and will not be supported in the nRF5 SDK.

    If your project is not bound to use the nRF5 SDK, we highly recommend to you (and all other customers) to use the latest version of Nordic's Connect SDK.

    Nordic's Educational Resources are based on NCS and we offer free courses with certificates on our DevAcademy which only is relevant to the NCS based designs.

    Getting started with NCS is pretty easy, I bed you will be running samples like "blinky" or "hello_world" within minutes: Getting Started: Installing NCS and VSCode

    /BR, Naeem

Reply
  • Hi Bernat,

    As you have pointed to the code:

    The function conn_params_negotiation() takes a number conn_handle as an input argument. It then passes this number (conn_handle) as a pointer (not the address of the number, but rather the number itself) to the app_timer_start() function.
    The function app_timer_start() has the following prototype:

    ret_code_t app_timer_start(app_timer_id_t timer_id, uint32_t timeout_ticks, void * p_context);

    the parameter p_context will be passed to the time-out-handler
    When we look at the timeout handler function ( update_timeout_handler() ), we see that the pointer p_context is not dereferenced, but just type casted and stored as a value.
    uint32_t conn_handle = (uint32_t)p_context;

    This could have been an implementation choice as the conn_handle is just a number and does not contain big data stored as a structure.

    Regarding the SDK, please go through Nordic's NCS and NRF5 statement.

    Please also note that Nordic is still supporting the nRF5 SDK in maintenance mode. This means that bug fixes and security updates will be available as needed. However, support for new features beyond Bluetooth LE 5 will not be added to the nRF5 SDK. For instance, Bluetooth Direction Finding, Bluetooth LE Audio, and so forth are not supported and will not be supported in the nRF5 SDK.

    If your project is not bound to use the nRF5 SDK, we highly recommend to you (and all other customers) to use the latest version of Nordic's Connect SDK.

    Nordic's Educational Resources are based on NCS and we offer free courses with certificates on our DevAcademy which only is relevant to the NCS based designs.

    Getting started with NCS is pretty easy, I bed you will be running samples like "blinky" or "hello_world" within minutes: Getting Started: Installing NCS and VSCode

    /BR, Naeem

Children
  • Hi Naeem,

    Thanks for your response. Oh I see, I never saw a pointer used this way, instead of storing an address it's directly holding the number... It's weird because the p_context is defined as a "void *", whose bit width is dependent on the platform, but in a 32 bit microcontroller it's usually 32 bit, so I see the concept a bit wrong but it's OK

    About the platform. I use a nRF52832, and I don't plan to move to a more powerful microcontroller. My firmware is quite simple, and I use a very small battery, so the time it's in sleep state is important, what means each clock counts and I prefer to prioritize the performance rather than modularity. I see the nRF Connect SDK uses a RTOS, which in my case is totally unnecessary. Do you have some performance comparison to see the overhead the nRF Connect SDK is adding? I could migrate it now that it's in the initial stage if the performance is not worsened too much.

    Thanks!

  • Hi Bernat,

    We are still supporting NRF5 in the maintenance mode and it depends on your application, choices and decisions to chose bare-metal (nrf5) or RTOS (ncs) solutions.

    One solution might not be optimized for all customers. It all depends on individual projects and how they are looking forward and what features do they require.

    From Nordic's pov, shifting to Zephyr RTOS based SDK (NCS) was a big decision. NCS was launched in 2018, and for sure Nordic is committed to NCS. You can see very active development and feature support in NCS.

    Please see NCS and NRF5 statement from Nordic: SDK Statement

    You will see table comparing features, and different questions / concerns answered.

    Please also look at this blog by Tiago: Technical Analysis of NRF5 and NCS 

    You might also look at this question regarding nrf5 and ncs: Question about Nrf5 and NCS

    With regards,

    Naeem

Related